System and Business Process Reengineering
with GRADE

Janis TENTERIS and Evalds VILUMS

Riga Information Technology Institute (RITI),

13, Skanstes St., Riga, Latvia,
Internet: jtenteris@swh.lv, evilums@swh.lv

Back to GRADE Modeler 4.0

Abstract

This paper describes the main work packages (WP) performed during system and business process reengineering with GRAPES (graphical specification) language and GRADE (Graphical Re-engineering Analysis and Design Environment) tool. The work packages are discussed mainly in their sequence within system life cycle. A short overview on diagram types for system modeling is included and the main features of GRADE tool are mentioned. The main concentration is on Business Process modeling and reengineering work package, which includes static analysis of business processes, simulation alternatives and principles of process and organization structure rearrangement. An example shows gradual improvement of business process model and its conversion to a person's job description and/ or Information System specification.

System modeling and re-engineering with GRADE includes the following main work packages (WP):

1. Registration and hierarchical arrangement of the main objects of the existing system;

2. Graphical representation of communication diagrams with main physical parts and functional objects of the system and communication between them;

3. Modeling of Business Processes:

a) description of existing business processes, modification of existing processes and creation of new business processes:

I. static analysis of business processes;

II. simulation of business processes;

III. evaluation and modification of processes according simulation results;

b) modification of organization structure;

4. Development of data model, including:

a) structured description of messages;

b) contents of the databases;

c) access rights to data;

5. Creation of functional specification of the system:

a) rough specification (Process Diagrams) of object behavior, including:

I. job description of organization units and positions and functions to be computerized;

II. specification of computerized tasks (to be completed by parts/ modules of Information System);

b) detailed specification of the Information system (design model with user interfaces);

6. Physical implementation model:

a) GRAPES 4GL model or programming according specification;

b) IS architecture and software implementation;

During these WPs an integrated GRADE model is created. The packages 1-4 correspond to analysis phase of the existing system, WPs 3-5 will be typical to design stage and WP 6 corresponds to implementation of the new system.This model is composed of a number of diagrams. GRADE also has different editors for creating, editing and displaying the information to be contained in a model. GRADE maintains all of these diagrams in a central repository.

This chapter includes a short summary on GRAPES diagram types. More detailed explanation can be found in a number of sources, e.g. [Held91], [GRADE95], [Barzd94].

Let us discuss this procedure in more details. Most of the diagram types (except for Object Tree) can be created and graphically edited via Modeler component of GRADE. The Registrator component of GRADE is useful during the WPs 1, 2, 3aI and 3aII only. However, the information accumulated by Registrator during 1^st WP can be exported and converted to Modeler diagrams also in the WPs 3 b and 4 a.

WP 1

The system diagramming can be started immediately from the beginning of project. However, before the creation of the diagrams through graphical editors it is more effective to start with registration of the main objects of the system. For this purpose Registrator (a component of GRADE toolset) can be used. It is designed for analysis of existing systems in the early stages of project development.

The system description consists of the following main objects:

The semantical meaning of the objects is as follows:

• Active Objects (AO) can be considered as subsystems and processes of the system (organization units, people, positions, equipment, computers, DBMS, etc.);
• Passive Objects (PO) are transferred among active objects or manipulated by them (documents, messages, files, diskettes, packages, etc.);
• Activities (AC) can be considered as functions of active objects and activities performed by them (print a report, approve a document, calculate value, store in database);
• Datatypes (DT) describe data images and structures of passive objects (attributes of engine, amount of money, structure of data file).

The hierarchical arrangement of objects can be defined via relationship 'consists of' or 'includes'. It can be changed easily with 'drag and drop' editing features of Registrator. The links between Active Objects can be described in terms of AO1 'sends' Passive Object 'to' Active Object 2. Relationships between Activities and Passive Objects can be described in terms of Activity 1 'consumes' PO 1 or Activity 2 'produces' PO n.

The relationships between objects are represented as Object Tree.

The hierarchy of Active Objects (more specific - hierarchy of organization units, positions and resources) can be represented in another alternative form - as an ORG diagram. This diagram can be converted to/ obtained from Active Object Tree (in Registrator) and/ or CD diagram tree (in Modeler). The main limitation of ORG diagram is the missing possibility to describe horizontal links (communication Paths) between objects on one level of hierarchy. However, the vertical links (between subordinate and super-ordinate objects) are represented in a rather friendly form and the diagram layout can be automatically converted from horizontal to vertical and vice versa. The 'drag and drop' editing is also enabled here.

The main goal of this WP is to understand the system completely, describe main active, passive and functional objects of the system and avoid misunderstandings due to unintended synonyms and homonyms in object naming.

WP 2

The graphical representation of main objects and relationships between them is represented as a Communication Diagram with Communication Paths and Interface Tables.

The CD diagram in GRADE toolset is available in 2 different forms:

• via Registrator - the CD diagram view is generated according the links between active objects. The diagram can be viewed and validated by the designer. Inconsistencies in the model and/ or in the system can be discovered by assessing the visible links between Active Objects. As a rule each AO is connected with other objects. From the graphical layout missing and lacking links can be detected easily. The hierarchical subordination of objects can also be validated through the generated CD views. If an AO has external communication paths (to objects represented in other diagrams) only then a possibility to move this object to another hierarchy branch or hierarchy level should be considered. Within Registrator the 'drag and drop' editing of object hierarchy can be performed easily. However, the layout of the elements in CD diagram cannot be edited in this mode;
• via Modeler - the CD diagram can be obtained, edited, modified and validated by the designer. The Communications Paths between objects can be opened and the contents of interface tables can also be viewed and modified. However, any changes in the hierarchy of objects is much more difficult and the contents of interface tables can be easily lost during moving of just one element to another diagram.

WP 3

Work package 3 deals with Business Process Re-engineering which is discussed in context of Business area modeling and Information System modeling. During last 5 - 10 years it is widely recognized (after great efforts directed to reverse engineering, re-engineering, down-sizing, right-sizing and so on of the legacy software) that changes in information systems do not improve overall efficiency of the business, if the organizational structure and organizational procedures remain old. Therefore the main goals of business re-engineering can be defined as follows:

• create reasonable (or even optimal) functional structure of a business processes. Besides GRADE BM (Business Modeling component) a number of other available tools and methodologies can also be used, e.g., Function Tree and Event Driven Process Chains approach (implemented in ARIS tool-set and SAP R/3 Analyzer), Function Tree and Function Net diagrams (used by Software AG tools NEW and Predict CASE), Graphs of Tasks implemented in MOSAIK V.4.1 and so on;
• obtain consistency between functional and organizational structures, and eliminate "weak points" and "bottle necks";
• ensure necessary IT support and homogenous information media.

To ensure modeling and analysis of business processes a special extension of GRAPES language, so called, GRAPES/BM was developed.

WP 3 a

GRADE tool and GRAPES language supports several approaches for modeling and analysis of business processes:

• textual (object based) description of the system, its activities and passive objects via GRADE Registrator. This approach enables information capture and good navigation possibilities within the model. The main limitation of this approach is the lack of graphical representation of task chains; However, this model (which was created basically in the 1^st WP already) can be converted to any of the following two models;
• process driven approach:
• create GRAPES-86 subset of the model (using Modeler or Registrator);
• add simulation script (Registrator) or imitation diagrams (Modeler);
• perform CD-level (and/ or PD-level) simulation;
• event driven approach:
• create GRAPES/BM (GRAPES for Business Modeling) model;
• perform static analysis;
• perform BM-level simulation.

The textual and process driven approach for Business Process Modeling was developed originally by INFOLOGISTIK GmbH and SWH Riga. The object based description in fact is a preliminary step for Process driven approach [Linaberg92]. The Process driven approach is described in more details in [Teilans96]. The event driven version of modeling language GRAPES/ BM was developed originally by Siemens Nixdorf Informationssysteme on the basis of know-how and experience from such systems as GRAPES SD, MOSAIK, WorkParty, ARIS etc. This approach was extended (Language GRAPES/BM 3.0 [Barzd96] and implemented in tool GRADE V3.0 by RITI and Institute of Mathematics and Informatics, University of Latvia. This approach represents graphically both a consistent set of diagrams including structure and functionality description. This model can be simulated and animated for dynamic analysis or viewed for static analysis.

WP 3 a I

Figure 1 TCD of the Planning And Organization task

The principles of static analysis of business model are heuristic and are quite understandable from common sense point of view. They are mentioned also in several sources, e.g. [Keller95], [Bhatt96] and can be summarized as follows:

1. it is reasonably to avoid organizational breaks between tasks, i.e., two consequent tasks have to be performed by the same active object if specific qualification or specialization is not needed to perform one of these two tasks;
2. it is necessary to ensure as homogenous information media between tasks as possible, shifts between information media have to be avoided;
3. information system support has to be ensured for each task where it is reasonably;
4. multiple capture or entry of information has to be eliminated;
5. it is necessary to exclude redundant performance of the functions;
6. try to create sections with parallel task execution instead of sequential whenever possible;
7. try to minimize number of different performers within one task chain;
8. try to minimize number of transitions from one performer to another performer during task chain;

Unless these requirements are stated rather informally, usage of them during static analysis stage helps to find "weak points" and "bottle necks". Let us consider an example of Business Process Model represented as TCD diagram Planning And Organization (see Figure 1). This diagram is part of [Maintenance] Employee Training Record System and describes how a Manager, Training Delivery department and Information system called MTRSystem (these are three performers of tasks) create plan and organize training for Employees of enterprise. The rounded boxes contain names of tasks and names of performers of tasks. The dashed line boxes represent references to remote or external tasks that are defined and specified in more details in another diagram. The hexagons represent decisions available after the task. The lines with arrows represent sequence of tasks and have also names of events (e.g. 'Decision' made, 'Request Catalogue' of Courses) that happen at the end of one task and are required to start the next task.

Only two performers (Manager and Training Delivery department) are involved in the execution of the internal subtasks. Taking into account that a scheduling of the training requires specific knowledge and experience we can conclude that the requirement (1) is met in this case.

However, the environment (media) of the information exchange between tasks changes from task to task:

• telecommunication facilities are used by manager to communicate with MTR system;
• lists of the employees to be trained as well as training schedules are sent via internal post or using e-mail;
• Scheduled Training Messages could be read by employees on the bulletin board or received via e-mail.

Figure 2 The modified version of Planning And Organization Task Communication diagram

Moreover, manager has to enter into word processor or e-mail text editor names of employees as well as course codes or titles unless this information is stored in data base and included in the Employee License Expiry Report and Course Catalogue. Once more input of the same information is needed during preparation of the messages for employees, even in the case when Manager uses copy/ paste to transfer data from received e-mail note Training Schedule to Scheduled Training message.

Thus, we can conclude that the business process represented by TCD on Figure 1 is not efficient enough from the requirements (2) - (4) point of view.

The modified version of this task communication diagram is presented on Figure 2, and the main differences between the previous version and the current one are the following:

• using editing facilities of the screen form (not print-out) Employee License Expiry Report manager adds (during execution of the task Determine Employees To Be Trained) the code of necessary training course to each row of the table and obtains in such a way Employees List in electronic form;
• number of the functions performed by MTRsystem is increased by defining the following additional ones:
• Support Scheduling function which has to be performed once a week and which results in preparing of Course Employee Matrix to facilitate scheduling process of the training;
• Messaging Facility function which is intended to control all the attempts to log-in into MTRsystem and to send all the prepared messages (if any) to system users, including Scheduled Training Messages to employees scheduled for training and Training Schedule Subset to managers (concerning only employees of the corresponding organizational unit).

Evaluating TCD on Figure 2 as a whole, we can conclude that:

• information media is fully homogenous (telecommunications), i.e. the requirement (2) is met;
• multiple entry of information is eliminated - this means that the requirement (4) also is satisfied;
• the modified version is better than the previous one from the requirement (3) point of view too, because in this case Make Training Schedule and Broadcasting tasks are performed by MTRsystem support;
• the total duration of the chain of tasks included in this TCD would decrease significantly, and managers as well as instructors from Training Delivery department would spend more time to performance of their basic functions (control of the maintenance procedures and training, consequently);

Figure 3 Fragment of ID diagram for simulation of communications of 'Manager'

• due to including of the additional and rather sophisticated functions in the MTRsystem costs of the development and maintenance would increase.

The principles of static analysis of business processes can be carried out in a similar way for any other business model regardless on the type of diagram representing the task chain. The same result could be obtained also on the basis of Event driven process Chain (EPC) diagram or even via Registrator without graphical representation of the process.

WP 3 a II

The simulation in GRADE is supported both according Process Driven approach and Event Driven approach.

The Process Driven approach is based on Communication Diagram. Each active object represented in this diagram has a simulation script (simple program created with syntax prompter of Registrator) or Imitation Diagram (created via ID editor of Modeler). In both cases this description includes separate fragments describing the generation of outputs (passive Objects) by the object or reaction of the object to incoming passive objects (see Figure 3). Thus the starting point of each fragment is GENERATE or RECEIVE statement. After that a new passive objects can be created and processed and the same or the new objects can be sent to the next step of processing.

The graphically represented simulation script (see Figure 3) represents just 2 fragments in the behavior of active object 'Manager'. The first of them shows that after receiving Expire report from MTRSystem Manager performs task Examine Report (average duration of task is 0.2 h), destroys the report and creates a 'Request For Catalogue Of Courses' and after task 'Make Request' sends it to MTRSytem.

This kind of simulation concentrates on performers of the tasks and the business transaction is distributed within simulation scripts of several performers. During simulation session the activities can be animated and the transfer times between active objects can be visualized and estimated. The transfer of passive objects between active objects is represented in animator as moving icons for each passive objects type.

The Event Driven approach is based on Task Communication Diagram. In this case the representation concentrates on activities or tasks and the animation shows execution of business processes as task chains (the active tasks are flashed red and the queues of messages in front of tasks are represented as green dots). The performers of tasks are also taken into consideration and they can be chosen flexibly by simulator according availability, competence and logical expression for selection of performers. This kind of business process simulation is more detailed and can describe virtually any business transaction.

Both simulation approaches can be used alternatively or sequentially. In a case of sequential use of both approaches the simulation model can be converted in both directions largely automatically.

The most important result of simulation is a number of statistical summaries and full simulation trace. The trace can be used to debug and validate the model as well as to explore the possible behavior of the system.

The statistical summaries of simulation results indicate total, maximum, average and minimum values of several attributes concerning task activation, performers and message transferring, e.g. waiting times, transfer times, queue length, frequency of events, dynamics of performers (idle and usage time), task costs and virtually any other user defined attribute.

WP 3 a III

The evaluation of simulation results is a heuristic iterative procedure. Each iteration will include modification of the model and repeated simulation. Within this WP the attention should be paid to the 'bottle necks' and 'weak points' of the system. They can be detected easily from the statistical summaries as the longest queues, idle times of performers, overloaded performers, long transfer time between performers within one task chain, etc.

In this WP a number of simulation experiments can be carried out. Before a new experiment the business model should be modified (improved). Typical activities during business model modification are:

• change sequence of tasks (concurrent versus sequential);
• change duration of tasks (or number of available performers);
• change selection criterion and/ or availability (working hours) of performer;
• reduce transfer time of messages (which means - foresee how to move a performer to another location or select another, less distant performer), etc.;

After changes in the model another simulation experiment should be carried out and the results should be compared to previously achieved. For the purposes of more convenient comparison the results of each simulation session can be exported in a spreadsheet format to enable formal comparison procedures and storing of intermediate results.

The question of optimal experiment planning also arises here. If formal methods are not applicable then intuition and common sense of designer combined with random search and evolutionary approach will be helpful in most cases.

WP 3 b

Modification of the organization structure is carried out according the modified and newly created business processes. In this WP ORG diagram can be modified manually according to the changes made in task chains. The typical changes would be:

• eliminate unused or mostly idle performers;
• merge similar positions in different organization units if they have high idle times;
• change number of employees with certain competence;
• move performers or organization units to another location (another subsidiary) or choose another communication channel for messages/ materials to reduce transfer times, etc.

These changes should merely restore a perfect correspondence between the task chains and the performer usage within these chains. For example, reduced message transfer time should be reflected here as different allocation of performers; reduced task duration means increased number of performers or assignment of performers with higher productivity and more competencies; etc.

If the modifications in ORG diagram may have a feedback to the business process, then repeated simulation session is recommended.

At the end of this WP the Communication diagrams with corresponding Interface Tables can be generated on the basis of ORG diagram and TCD diagrams. The set of CD diagrams obtained will show the new organization structure as well as the communications between objects, including names of messages to be transferred and all senders and receivers of each message.

Data modeling in GRADE is based on Data Definition (DD Datatype) diagrams and DD ER (Entity Relationship) diagrams. Physical allocation of databases and access paths to data are represented in Communication diagrams and Task Communication diagrams as 'data stores' with corresponding Access Paths.

The data modeling on a high level can be started already in the work packages 1 and 3. In WP 1 all relevant fields of documents, messages and other passive objects can be registered. Registrator supports modeling of record and set structures. For each field of record the formats can also be specified. The preliminary description of passive object data images from Registrator can be converted to graphical representation (DD diagrams in Modeler).

In WP 3 'data stores' and 'data objects' can be associated with tasks in TCD diagrams.

Figure 4 Process Diagram representing job description of 'Manager'

Each data object is associated with one user defined or basic datatype and is represented graphically in TCD in connection with tasks creating or using values of this datatype. Thus each data object corresponds to one variable or one instance of passive object used within the business transaction.

Each data store corresponds to an eventual database (or part of database) of the system. Access Paths link tasks or active objects with one or several data stores. The access rights (read only, add, delete, update or general) are specified in the corresponding Access Table.

Each data store can be associated with ER model which is represented graphically as Entity Relationship diagram with J. Martin notation (crows feet). ER model can be created from scratch by graphical editor or obtained during data analysis via DAF (Data Analysis Facility), DDW (Data Designer Workplace) or any other data modeling tool.

Common to these data modeling facilities is the fact that they produce a high level data model (business data model). The main purpose of WP 4 is to create a more detailed data model for the new information system. This data model should include the following information:

• structured description of all messages and data objects down to the level of fieldnames and preliminary specification of basic formats;
• contents of all databases represented as normalized ER diagrams with valid entity names, associated datatypes, primary keys, relationships between entities and foreign keys.
• for each database the physical allocation and access rights for each task and active object should also be specified at this stage.

Figure 5 Functional specification fragments after modification (a - MTRSystem, b - Manager)

Further refinement of data model (e.g. indices and denormalization to improve performance, technological entities and fields) can be continued in WPs 5 b and 6 a.

WP 5

The functional specification of objects in GRADE is represented as Process Diagrams. The first idea about functions performed by a certain object can be obtained from ID diagram (see Figure 3). However, the ID view on behavior of object is fragmented and it concentrates on simulation parameters mainly.

A more precise and consistent view on behavior of each object is represented through PD Process diagram (see example of the PD Manager in Figure 4)

WP 5 a I

This Process Diagram can be obtained largely automatically from the corresponding fragments of TCD diagram, CD diagram and contents of Interface Tables showing messages transferred between Manager, Training Delivery and MTRSystem. The PD diagram corresponds to the Manager's tasks represented in TCD (see Figure 1) before modification.

This diagram includes typical constructions for GRAPES 86 process specification. After the branching point (called 'Selective Wait') a number of RECEIVE statements are depicted. Each of them can be performed as soon as a corresponding message arrives and Manager is not busy with other activities. After RECEIVE statement each branch typically describes a number of activities to be performed and/ or decisions to be made. At the end of branch as a rule there is one or several SEND statements to represent the reaction to the received message.

At this stage of the project the tasks for computerization should be selected. The selection can be done from this PD diagram by selecting branches or separate statements to be performed by Information system. More conveniently this selection can be done on the basis of TCD diagram. In this example the modified version of TCD (see Figure 2) depicts possible changes in the business processes after enhancements in the existing Information System. The task Broadcasting is slightly modified (compare it with the corresponding task in Figure 1) and in the new version it will be partially performed by MTRSystem within the task Messaging Facility. These modifications should be reflected in corresponding Process Diagrams in the next WP.

WP 5 a II

In this WP the software specification for tasks to be computerized should be created. Obviously the diagrams representing manual functions should also be changed to keep the model consistent. In this example part of the third branch of PD Manager (see Figure 4) will be represented separately - as a specification of functions to be performed by a program 'Messaging Facility'. The corresponding fragments of Process diagrams are depicted in Figure 5. In these fragments we see also the communication between the MTRSystem (see SEND statement with Training Schedule Matrix to Manager) and Manager (RECEIVE statement with Training Schedule Matrix from MTRSystem).

Figure 6 Detailed design specification fragment

WP 5 b

The detailed specification of the Information system would be created for the computerized functions only. So in this example we have finished with the description of Manager, Training Delivery department and other manual objects and functions. From this moment the components of MTRSystem would be refined according to the following principles:

• a datatype definition should be completed down to the level of basic formats and necessary variables should be declared;
• each RECEIVE statement should be converted to INPUT via screen form or file;
• each SEND statement should be converted to SCREEN OUTPUT or REPORT statement;
• the INPUT and OUTPUT statements should be supplemented with required event and keyboard control processing within the process diagrams;
• each parallel control flow should be converted to sequential activities;
• each informal assignment statement should be converted to draft description of assignment or data manipulation in terms of variables and expressions; textual comments at this stage are still allowed;
• the required screen and report forms should be created and linked with the corresponding datatypes;

This description can be verbal, informal. It should understandable to the software engineers and programmers who will use this in the next WP. The style and level of formality of such description depends on the target programming platform. This results in a detailed specification for a programmer (see example for MTRSystem in Figure 6). This example is obtained from the fragment depicted in Figure 5 a.

WP 6

The physical implementation model supports transition to executable programs in the (area of Information system) and to new business processes (in the area of business model). From GRADE tool point of view there are two alternatives in this WP.

WP 6 a

The detailed specification of system can be used for automatic system generation within GRADE. In this case the specification from WP 5 b should be formalized completely. This means conversion of software specification (in language GRAPES 86) to executable model (in language GRAPES 4GL). During this WP the following activities should be done:

• all statements in the specification should be filled in via syntax prompter with correct GRAPES 4GL statements; This concerns all activities listed in WP 5 b.
• datatype description should be completed with the most appropriate basic formats and attributes for datatype validation;
• ER model should be adjusted according to high performance relational database principles (index fields, technological fields and entities, etc.)
• The screen and report forms should be completed, including necessary field validation expressions and subroutines, convenient layout and friendly help and message display;

This model can be used for generation of:

• resource files for MS Windows GUI screen forms;
• database layout (for virtually any DBMS, including ORACLE, INFORMIX On-line, SQL Base, SQL Server, etc.)
• 100 % executable binary file (for MS DOS, MS Windows or UNIX);

Another alternative for this WP is manual programming instead of code generation. This is actual, if the projects prefers a specific development platform or programming language. The programming (coding) is carried out according to the specification created in WP 5.

WP 6 b

This WP concerns implementation of programs on site. Depending on the requirements this may include setup and implementation of communication network and workstations, installation of required databases, system software and application software components.

Conclusions

The suggested sequence of system and business process re-engineering is developed during a number of large system analysis and software development projects. The sequence of WPs is typical to sequential life cycles with possible iterations in some sections of the life cycle. The Registrator and Modeler tools are methodology independent - they can be used flexibly according any other system development methodology. However this paper emphasizes the advantages of these tools to convert automatically different views of the model. These conversion features can be used more effectively according the outlined sequence of work packages.

REFERENCES

[Barzd94] Barzdins J., A.Kalnins, K.Podnieks, et al. 1994. "Unified Specification Language and integrated CASE Tools for Information System Development". Proceedings of the Baltic National Infrastructure Databases. Trakai, Lithuania. Vol.2. pp.24-34

[Barzd96] Barzdins J., A.Kalnins, K.Podnieks, et al. 19964. "Business Modeling Language GRAPES/BM and Related CASE Tools". These Proceedings

[Bhatt96] Ganesh D.Bhatt. 1996. "Enterprise Information Systems Integration and Business Process Improvement Initiative: an Empirical Study". Http://hsb.baylor.edu/r…r/acis/papers/bhatt.htm.

[GRADE95] GRADE Version 2.0. Modeler, Registrator, Simulator: User Guide. 1995. Infologistik GmbH, 23 Budapesterst., Munich, 608 p.

[Held91] Held, G; 1991. GRAPES Language Description: syntax, semantics and grammar of GRAPES-86. Siemens Nixdorf Informationssysteme AG, Ed.: Gerhard Held, Authors: Rudolf Haggenmüller et al. - Berlin; München., 304 p.

[Keller95] Keller G., W. Brenner, (Eds) Business Reengineering mit Standartsoftware, Campus Verlag, Frankfurt, 1995

[Linaberg92] Linabergs L., Vilums E. 1992. "System Analyst's Integrated Environment within GRADE CASE Tool" Proceedings of the Nordic Workshop on Programming Environment Research.- Tampere, Technical University, Finland. pp.6.1-6.10.

[Teilans96] Teilans A., A.Kleins, U.Sukovskis et al. 1996. "Simulation Approach and Modeling Tool for Large Scale Systems: Registrator". Proceedings of the Simulation Multiconference, Simulators International XIII, March 31 - April 4, 1996, New Orleans, Louisiana.