Instrumental approach to programming in MultiOberon system

Dagaev Dmitry Viktorovich ORCID: 0000-0003-0343-3912 General Director, SCADI LIc 115230, Russia, Moscow, Zeleny Prospekt, 5/12, building 3, room 1 dvdagaev@oberon.org Other publications by this author

Introduction

Object-oriented programming approaches, as well as other methods, have their own area of applicability. For some tasks, understanding the types of "everything is an object", "think like an object" is a natural way to build architecture. For other tasks, object constructions represent an extra level of abstraction that is not explicitly related to the problem being solved, but has clearly expressed cost indicators in the form of redundancy of computer resources.

It should be noted that even proponents of OOP recognize the locality of their proposed solutions, for example, in ^[1] the world is divided into areas where the object paradigm and the paradigm of classical structural programming are divided along the axes "knowledge-social world" and "implementation-deterministic world". Developers of the fields of the deterministic world, who prefer classical approaches based on algorithms and data structures, agree with this statement ^[2]. At the same time, an important direction is to achieve the object world in terms of abstract access through interfaces and organization of interaction.

The programming language and the Oberon system ^[3] have historically been based on a minimalist classical approach, with polymorphism in the expansion of data types. Later, Oberon-2 developed in the form of adding methods, and the Oberon-07 family developed towards the exclusion of object, dynamic functionality for subsequent use in controllers and other embedded systems.

The author proposes and uses a restrictive semantics approach, which uses a single language and a compiler frontend with a system of semantic constraints instead of several languages and compilers. Multioberon is a software implementation of the Oberon compiler with a system of semantic constraints^[4].

Multi-domain solutions to problems from the deterministic world required limiting the semantics of working with objects available in the language and using classical data structures. This raises questions about interfaces and abstractions for accessing data.

In this article, an instrumental approach is proposed, in which instead of the interface of an object containing data of an unknown structure, the interface of a tool that does not contain data and is associated with a data instance is used. The tool, unlike the object, is not allocated in dynamic memory, does not require serialization/deserialization, and cannot lose data in case of an emergency due to an exceptional situation.

The concept of a tool is transparent, if we take an analogy with the creation of a sculpture through processing in different phases with different tools from roughing to finishing.

The instrumental approach is in good agreement with data-centric programming, when programs are separated from data and connections between each instance of the data structure and the program can be instantly and unambiguously established.

 The instrumental approach is especially advantageous to use in 24x7 systems of a deterministic world, where the lifetime of data can significantly exceed the lifetime of programs if persistent data in shared memory is organized in the system.

Object thinking versus Structured Programming

Enough has been said about the advantages of OOP, much less about the areas of effective application. And these areas of effective application do not cover 100% of the tasks that arise. In addition, when using object-based approaches, the technological culture of software production changes, based on completely different abstractions than classical approaches. Abstracting from data structures and focusing on interfaces as rules undoubtedly has advantages in terms of a more systematic presentation of each subject area. In this case, the object becomes a kind of universal entity, but at the same time loses its unique features in terms of data structures. Therefore, it makes sense to apply the decision on the use or non-use of OOP at the earliest stages of creating software systems.

What are the guidelines and what are the options? D.Hersh in ^[1] considers the axes "knowledge-the social world" and "realization-the deterministic world" (Figure 1).

Fig. 1. The axes of knowledge-the social world and realization-the deterministic world

Fig.1 Comprehension-Sociocultural world and Implementation-Computer Science

The separation of the areas of use of OOP for knowledge and the social world and classical structural programming for systems of the deterministic world or those in which implementation prevails seems logical, especially considering that it was formulated by the OOP theorist.

In this article, we will consider approaches to the implementation of deterministic world systems.

Data-driven programming

Deterministic programs are characterized by the primacy of data and state, in such tasks data-driven programming technologies (data-oriented programming DOP) are often used, the basic principles of which are set out in ^[5].

Data-driven programs are designed to build loosely coupled systems using recovery mechanisms. The principles of data-driven programming dictate the following solutions.

1.      Provision of data and metadata. In direct contrast to encapsulation in OOP, software status data is provided within the access rights of software components. Metadata contains information about the name, type, and further on the composition of the nested types included in this type. Such a representation should provide sufficient information for the formal machine of the abstract performer to read and execute the presented data.

2. Hiding the details of the code. DOP hides the program code and is based on messages between components. The interface is a non-critical property of the system. All we know is that there are some loosely coupled systems in a distributed configuration. Unlike OOP, there is no dependence between objects and, as a result, there is no mutual influence.

3. The separation of code from data is also the principle of DOP.

4. Data processing should be based on the metadata of the implementing platform.

An important feature of data-driven programming is data persistence. The lifetime of the data becomes longer than the lifetime of the program code. Even in case of software failures and recovery, data recovery is not required.

Figure 2 illustrates data failure and recovery in the OOP system and in the DOP systems at the top and bottom, respectively. A failure results in the exclusion and shutdown of some software component. In the case of OOP, when a failure occurs, it becomes necessary to serialize data into temporary storage, which is rarely implemented correctly. Data deserialization should be performed during recovery. After the restoration, the connections of the objects addressing this one should be restored. All these mechanisms are quite problematic in terms of implementation, especially for an event in the form of a program failure.

In the case of DOP, an emergency shutdown and restart of the software module is performed. No other actions are required, provided that the code is separated from the data. Restoring connections for objects addressing this one is not required, because all connections between objects are provided with metadata of the implementing platform and are in persistent memory.

Fig. 2. Saving and restoring OOP and DOP data

Fig.2 OOP and DOP date saving and retrieving

Code separation from data also means storage separation, when data is stored in persistent memory and codes are stored in memory into which the software module is loaded.

Semantic limitations of the Multioberon

The implementation of software loading and reloading can be provided either at the process restart level, or by means of a language that supports modular programming. Oberon^[3] is a modular programming language. Each software module is a unit of storage, compilation, loading and execution.

The construction of systems with increased requirements for functional safety leads to prohibitions on the allocation and use of dynamic memory. In the Multioberon system^[4], these prohibitions mean that the NEW function cannot be called directly in the module. Therefore, the allocation of dynamic memory is declared as missing. Of course, such definitions should cover all modules under consideration. In addition to considering the limitations of the imported module, you can prohibit the use of system transformations that use data from external functions.

RESTRICT –NEW, -SYSTEM;

If the keywords NEW and SYSTEM are present, the check will not be passed and will result in a syntax error.

An instrumental approach instead of an object approach

The rejection of dynamic allocation leads to changes in the mechanism of implementation of program methods. The first method, obviously, should use the approaches of classical structured programming. The second method can use static objects without passing and assignment as pointers. Both of these methods lose the inherent ability of OOP to build systems and patterns according to interfaces^[6], and substitute implementations as matching a certain interface.

The author suggests an instrumental approach, which consists in creating a tool that does not contain data instead of an object. A pointer to a tool, like a pointer to an object, can be used for substitutions and assignments of both this and all basic types. The pointer to the tool addresses the type of data stored in the module's memory. Table 1 shows the differences between the tool and the object.

Table 1. Differences between a tool and an object

Table 1. Tool and object difference

Getting a tool with the TOOL system function

The TOOL system function with one argument is designed to query the tool. For example, the TOOL function returns a stdlog pointer to a tool of type StdLog.Hook. The tool is a record that does not contain any data fields. The pointer to the tool is used as the interface of the information output console.

TOOL(stdlog);

stdlog.String(“Tool for an object”); stdlog.Ln;

The tool type must be defined in the variables section.

VAR stdlog: StdLog.Hook;

Repeated and all subsequent calls to the TOOL system function will result in the return of the same address.

TOOL(stdlog2); ASSERT(stdlog=stdlog2);

Because the type  StdLog.Hook contains methods and does not contain data, so there is no need to allocate additional memory for each instance of the tool. This is the main difference between the TOOL system function and the NEW system function.

Fig. 3. Getting the address by the TOOL and NEW operators

Fig.3 Retrieving and address by TOOL and NEW operators

Definitions of structure types in the Oberon language are contained in the metadata available for each software module (Figure 3). In particular, the metadata defines an array of inherited types, starting from the most basic and ending with this type. The pointer to the tool contains the address of the cell next to the type tag. The contents of the addressable cell do not matter, because the tool does not contain data fields. The addressable cell is located in the metadata area of the module. Each TOOL call returns the address of the same cell.

In turn, an object with data in dynamic memory must also contain a type tag and return the address of the cell following the type tag. In the figure, the object contains dynamic data "Field 1" and "Field 2".

Using a standard addressing mechanism with a type tag allows you to work with pointers to tools as pointers to dynamically allocatable objects.

However, there is an important difference between these pointers. Pointers to dynamic objects are processed by the garbage collector after completion of use. The garbage collector is not applicable to pointers to tools. Therefore, the tool keyword must be present in the definition of the pointer to the tools. For example, for our example with the information output console.

Hook = POINTER TO RECORD [tool] (Log.Hook) END;

The use of the TOOL system function is allowed only for pointers to tools.

Extension of the basic tool type

The StdLog data type.The Hook includes a pointer to the tool and the methods used. In our example, it is an implementation and extension of the basic Log.Hook type. The base type is abstract. Its definitions define the interfaces required for implementation.

MODULE Log;

RESTRICT +TOOL;

Hook = POINTER TO ABSTRACT RECORD [tool] END;

PROCEDURE (log: Hook) String* (IN str: ARRAY OF CHAR), NEW, ABSTRACT;

PROCEDURE (log: Hook) Ln*, NEW, ABSTRACT;

The installation of the tool with the StdLog type obliges to implement all abstract functions in the codes so that it is possible to substitute the log implementation instead of the abstract log interface := stdlog. Then each call to log.String() will result in a call to stdlog.String(), and the software architecture can be built according to patterns and interfaces.

When implementing a different version, for example, in the MyStdLog module, the pointer will be assigned a different log value := mystdlog, the address of which will differ from the previous implementation.

Since the use of tools is an extension of the language, the inclusion of mechanisms with [tool] flags requires the removal of semantic restrictions on tools. This is done by the RESTRICT +TOOL operator.

Association with data

Data-driven programming technology assumes the presence of data separated from the program code. This raises the question of which tool to use to process each instance of data. The metadata of the implementing platform must be used. What does this mean for the instrumental approach?

Tools for processing this structure can be associated with the data structure. There may be several tools, and different tools are used at different stages of processing.

Fig. 4. Tools associated with data

Fig.4 Tools, associated with data

The metadata of the implementing platform is required to obtain a pointer to the tool for each data type and tool number. If there is no association for this number, then, of course, a null pointer is returned.

It should also be added that there is a need for effective access to obtaining the tool. Trees and associative arrays are not suitable for these purposes, direct index access is required at the level of information in metadata.

The Multioberon implements efficient index access to tool pointers, Figure 5.

Fig. 5. Index access to tools

Fig.5 Indexed tool access

To store pointers to the type of the tool, free cells of the array of inherited base types of the Kernel.Type structure are used. The size of the array is 16, which reflects the maximum depth of nesting types. When using the instrumental approach, nested types are used less intensively. To associate with the first tool, cell 15 is used, with the second – 14, etc. The maximum number of associated tools will be determined by the compiler.

Using data tools

To use the Update interface in relation to Data data in the OOP, the Data object is installed and the Update method is called, which can be virtual and replaced by implementations for specific subtypes of Data.

var Data data;

data.Update(flags);

The use of the instrumental approach assumes the presence of data in the persistent domain and the request of tools to them.

VAR data: Data; tupdt: DataUpdate;

TOOL(tupdt, data, I_UPDT);

tupdt.Update(data, flags);

The TOOL system function with three arguments is designed to query a tool associated with a given type by interface number (in our case, IFACE_UPDATE). The resulting tool is applied to the data by calling the Update method with flags.

The cost of separating code and data is less expressiveness of the code compared to the OOP option.

The data association of the tool is set statically when defining types.

CONST I_UPDT = 1;

Data = RECORD

   x, y, rad: INTEGER

END;

DataUpdate = POINTER TO RECORD [tool] (IUpdate, Data, I_UPDT)

END;

The I_UPDT constant defines the instrument number. In the definition of the tool, it is laid down that the tool is associated with the Data type Data under the number I_UPDT.

Naturally, there is no need to request a TOOL(tupdt, data, I_UPDT) before each method call. This can be done once and then use the tool with the data related to it.

Identified problems and characteristics of ergodicity

The problem of saving and restoring saved data in case of failures and terminations of software system modules does not have a simple solution for object architectures. In complex object systems, saving requires serialization, and recovery requires deserialization, which is not always possible if the distributed system is partially inoperable. As a result of such restoration, it becomes necessary to bring objects to the required state, which does not always happen. This is characterized by external manifestations when the system is working, but not in the entire set of properties.

In ^[7], a number of reasons leading to degradation of the properties of a computer system over time are considered. An important criterion is ergodicity, i.e. the stability of these properties, which requires evidence, including of an architectural nature.

Using data in fixed persistent stores makes the lifecycle of changing system states more predictable. Data in such repositories is dumped into temporary files and restored from them.

The second problem of recovery is related to the fact that such a recovery requires a mechanism to restart and bring the data into line. When separating code and data in case of failures in software code modules, there is no need to unload data structures from memory. The code module can be overloaded if necessary, and the data remains in memory. The instrumental approach guarantees that there is no data to be initialized, because tools, unlike objects, do not have data fields.

The third problem is the excessive flexibility of the system architecture of the implementing platform. Flexibility means that the data structures and behavioral characteristics of the object system will be uncertain, which will not allow us to assess the change in the state of the computer system. In the case of the instrumental approach, the data structures become more defined, and the architecture of the system becomes more predictable. The certainty of data structures means that the state of the system is determined by these structures, and only by them. And, consequently, the stability of these data structures will lead to an improvement in the ergodicity characteristics of the system as a whole.

The fourth problem is the applicability of solutions for compact firmware without using pointers to objects located in dynamically allocated memory. The pointer to the tool is by definition the only one and does not require placing an instance of the object in memory.

The instrumental approach and architectural solutions related to the separation of code and data lead to more stable and provable systems. The ergodicity characteristics of the proposed approach become better due to the explicit state stored in data structures. Ultimately, the dynamic behavior of the system is determined by the state and sequence of input influences, and the more stable the initial state, the more predictable the final state will be.

Other solutions and approaches

Object representation methods cover both the representation of data and metadata ^[8]. Moreover, object models based on design patterns are currently most widely used for tasks of the knowledge-social world axis ^[9-11]. The most important difference between object-based approaches is that both data and metadata are objects that are called remotely via an address. When downloading/restoring program codes, these addresses, as well as links to them, change and are subject to initialization.

The lifetime of the object system code modules will be equal to the lifetime of the system itself. For solutions related to the separation of code and data, the lifetime of the system will be equal to the lifetime of the data modules and exceed the lifetime of the code modules.

An important mechanism for increasing the lifetime of systems is the principle of "orthogonal persistence" ^[12], which determines the mechanisms of independent data state preservation. The application of this mechanism for Java systems was described in ^[13]. The real big step was the development of the Phantom OS (Digital Zone, Russia), built on the principles of orthogonal persistence. A common instrumental approach and an orthogonal persistence approach is unstressed state preservation and restoration mechanisms. But there are important differences. The instrumental approach makes it possible to implement recovery systems based on both standard operating systems and for mission-critical systems where operating systems are not recommended or explicitly prohibited ^[14]. The instrumental approach does not require the use of a garbage collector, which "is a serious problem for operating systems" ^[15]. The microcosm and real-time systems impose even greater restrictions on the use of mechanisms such as garbage collection. The application of the instrumental approach is more consistent with the "implementation-deterministic world" axis and is the preferred mechanism for this area.

Application in SCADA Platform software

The instrumental approach was used in the development of the SKADI software (information on https://scadi.tech ), which stands for means of complex automation and diagnostics. The distributed architecture of SKADI consists of nodes interconnected by network protocols. Each node is a network-addressable computer with SCADI software installed.

Handlers access shared memory data, including tables and message queues. SCADI synchronization tools ensure the identity of data on any node with checks and diagnostics if synchronization on the nodes is not provided.

The general scheme of updating data on message queues is shown in Figure 6.

Fig. 6. SKADI data processing

Fig.6 SCADI data processing

DsDVP software services update the tabular data of nodes based on the input values of message queues. The DsDVP program associates a processing plugin with each type of data in shared memory. Processing plugins contain executable tool codes corresponding to the specified data types. When switching states, automatic mechanisms are involved ^[16], reduced to the form of a tool – data structure.

For example, the AI analog data processing plugin contains OvhAI tools, and the DI discrete data processing plugin contains OvhDI. In this case, the AI analog data processing object contains data without methods, while the OvhAI analog data processing tool contains methods without data.

Conclusion

The instrumental approach proposed in this article allows us to preserve the advantages of classical structural and object-oriented programming. At the same time, the instrumental approach works in a data-driven programming infrastructure. Polymorphism and the ability to work on interfaces are taken from the object-oriented approach. The definition of data structures and interaction with them are taken from classical structural programming. Data-driven programming uses the separation of code from data and the life cycle of the latter in a persistent form.

Saving and restoring data allows you to build software systems based on an instrumental approach, in which data is located in specialized, separately structured areas. Saving and restoring such data does not require serialization/deserialization operations and can be performed atomically. This is especially important when building highly reliable 24x7 systems that are resistant to failures in the code of software modules. In turn, program codes are concentrated in tools that do not have a state and, therefore, do not have to save and restore this state.

Tools are software objects without data that are in a single instance for each type. This allows you to avoid using dynamically allocated memory for objects, since the absence of data does not require the absence of an instance in memory. At the same time, the tools can be called and the associated data structure objects can be updated.

The disadvantage of the instrumental approach is the lower expressiveness of the code compared to the OOP code. Both the tool itself and the associated data instance must be present in the semantics of the tool call.

The instrumental approach is implemented in the Multioberon system. The restrictive semantics of the Multioberon allows you to disable the functionality of the OOP and enable the functionality of the instrumental approach.

The "free from limitations" approach involves developers declaring the fact that an instrumental approach is used, which means that all data states are stored in persistent memory. These declarations may be due to the desire to improve the quality of the system being developed or design requirements.

The use of tools and persistent data warehouses greatly facilitates the consideration of ergodicity issues. Such developed software will degrade less over time.

The construction of a SCADI system with the requirements of increased reliability is implemented using an instrumental approach. This solution allowed us to take another step towards improving the quality of the software product for building software of critical systems.