• Nem Talált Eredményt

PCUBE, the ancestor

In document Óbudai Egyetem (Pldal 104-108)

7. The bases of computerized governance support in PCUBE-SEC

7.2 PCUBE, the ancestor

Parallel processes are, roughly speaking, such processes, that execute some of their steps at the same point of a kind of virtual time. Concurrent processes are such parallel processes, that compete for the same resources. The most important design goal of PCUBE - or shortly P3 - was to support the modelling, Planning and simulation of Parallel and

concurrent Process systems, to find such a scheduling, such a cooperation of these parallel, or even concurrent process systems, that satisfies the user-given goals [Szenes, 1987].

This modelling tool was later used in investigating the scheduling possibilities of such web services, that are the building blocks of service oriented architectures [Szenes, 2006, SOA].

The four layers of PCUBE are:

• a problem-friendly AI style users' problem description facility

• traversing trees corresponding to this problem world

• implementation the traversing + time maintenance + resources in list processing

• implementing the list processing level on base level.

The architecture of PCUBE is a hierarchy of these levels. To these levels different process modelling styles, implementation tools, type structures, and also different user problem description support belong.

The syntax of the top level, that of the user problem description is PROLOG-like, but this similarity exists only at the top level of the system. The overview of the PCUBE implementation layers will clearly show, that already the basic architectural concepts are totally different from those used generally by PROLOG experts.

This multi-layered architecture facilitates a rich process and process systems description, together with such a planning of process execution, that results in deadlock-free series of process steps.

This mixed diversity of positive characteristics is due, on the one hand, to the user-friendly problem description at the top level of PCUBE, that explicitly requires rather the knowledge of the problem to be solved, of the "what", than programming skills, the "how", and, on the other hand, to the multi-layered implementation.

My basic idea in developing PCUBE had been translating the users' problem world description, consisting of the preconditions of the execution of the individual steps of the users' processes first into a problem of traversing trees corresponding (more or less) to the individual processes.

As I had already had practice in using list processing for writing AI programs, from the time of writing my university doctor dissertation in 1976, it seemed to me quite natural to

implement this tree-traversing also in a list processing language, developed just for the purpose [Szenes, 1976-77], [Szenes, 1987, 1988].

The list processing language, could, in its turn, be implemented in a low-level, efficient code [Szenes, 1987]. This code had first been FORTH, [Forro], then, some years later, C [Palossy, Tempfli]. This way I could get rid of the disadvantages of the PROLOG-like interpreters, that had been a little slow, and required ample storage, that meant a drawback in the eighties.

This method of construction could even facilitate the concrete real time control of the execution of the user's process systems. In other words, the PCUBE process model is actually a time and / or execution table of the steps of the processes to be followed to achieve the user - given goal.

In the case of production processes this would mean the actual controlling of the machines themselves, according to the "successful" series of steps, that PCUBE had built - discarding, of course, those parts of the solutions, that lead to deadlocks. Of course, to perform this plan, machine-controlling facilities are to be added to PCUBE.

Both the knowledge bases of PCUBE and that of PCUBE-SEC contain facts known on the problem to be solved. The task of PCUBE was to find such solutions, using the knowledge base, that describes the different possible ways of the cooperation of the processes that reach the given goal(s). The task of PCUBE-SEC is to give back those parts of the receipts, those parts of the knowledge base, that lead to the users' goals, under the given preconditions.

On its top level PCUBE offers a wide scale of process interaction facilities, that I had learnt from such sources, as the basic article of Hoare on communicating processes, and the - I think - best modelling language with the already mentioned, remarkable object orientation, SIMULA [Dahl et al., SIMULA 67], [Hoare]. The SIMULA facilities gave the idea for the instructions, that described parallelism. The monitor concept, that I renamed as "resource", came from Hansen's Concurrent Pascal [Hansen]. This is the notion, that is needed to describe concurrency, as this is the resource, that is needed by the processes, but its use is exclusive. If one process uses it, then the others have to wait. The idea of the time-handling instructions, that express, that something happens BEFORE, AFTER, etc. some other event, or a process WAITs for a time interval, I took also from SIMULA.

My contribution to the T-PROLOG project had been just the description and specification of these SIMULA- and Concurrent Pascal-like features, in order to help the colleagues to include them into this PROLOG-based simulation language [Futó, Szeredi, J., Szenes]. The idea to extend PROLOG with time maintenance is due to Ivan Futo.

Due to the PROLOG base the T-PROLOG process handling was deadlock-free. PCUBE is also able to derive deadlock-free plans for process execution because of its tree-traversing layer.

On the list processing level of PCUBE and thus that of PCUBE-SEC, to a simple knowledge base statement such a list corresponds, that consists of the series of characters comprising the simple statement, this is such a list, that consists of a head only, and has no tail. To the complex statement corresponds a list composed from its head and tail.

Developing the list processing level of PCUBE, first I had to define the list traversing instructions. The lists have to be traversed forwards, and backwards, too. Composing new lists from existing lists had also to be described. All these instructions were based on the notion of successor and predecessor, as this is actually the notion, which is needed to describe the tree traversing.

To facilitate the time- and resource handling in PCUBE, I wrote a scheduler, in the list processing language, based on my experiences with job-scheduling on mainframes, and on the ways of processing the interrupts by the means of interrupt drivers, according to the customs of the old assembly "world". For the scheduler I got some ideas from the CDC 3300 job scheduler, too.

Having specified this scheduler, I gave it to my already mentioned students, who wanted to program the base level, as diplom theses first in FORTH [Forro], then in C [Palossy, Tempfli].

It must be noted, that the facilities of my list processing language also took after those of SIMULA 67, as I had written my AI system in 1976 in SIMULA, on a CDC 3300, exploiting the really very extensive, and, at the same time, exceptionally comfortable SIMULA list processing facilities. The AI feature was providing for such robots' thinking facilities, as those of WARPLAN, that had been written in PROLOG, by David Warren [Warren], [Szenes, 1976-77].

"Thinking" meant, that the robot had to compose at least one series of steps from a given set of possible steps, that led to a given goal. In other words, it had to find at least one way to achieve a given goal, under given preliminary conditions. In my doctor dissertation I had illustrated the deadlock handling capabilities of my system with some examples.

In document Óbudai Egyetem (Pldal 104-108)