System and Business Process Reengineering
with GRADE

Janis TENTERIS and Evalds VILUMS

Riga Information Technology Institute (RITI),

13, Skanstes St., Riga, Latvia,

Back to GRADE Modeler 4.0


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.

Sequence of Work Packages

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.

Summary of GRAPES diagrams

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].




Diagrams for declaration of hierarchy

Object Tree

Represents preliminary description and relationships between main system's objects (Active Objects, Passive Objects, Procedures and Datatypes).


Diagram Tree

Represents hierarchical subordination and associations between GRADE diagrams. Each diagram provides further refinement and more detailed description of the main objects.

Diagrams for structure and communication modeling

Communication Diagram

The Target System and Environment are displayed, constituent parts of the Target system are displayed in lower level CD's. Each CD represents Active Objects and communications between them as well as the access from Objects to Databases.


(organization structure) diagram

The organization's structure is described in terms of organization units, positions and resources. Each of them can have such attributes as competencies, availability, cost, number of instances, etc.


Interface Table

A table is associated with communication path between 2 Active Objects and displays in tabular form all Passive Objects passed between them.


Access Table

Is associated with access path between an Active Object and Database and displays in tabular form accessible entities and access authorization.

Diagrams for data modeling

Data Diagrams

Display structure of data contained in an Interface Table, Data Table and Database.


Entity Relationship Diagrams

ER's are a subtype of Data Diagram that graphically display all of the Entities to be stored in a Database and relationships among them. Each Database can be associated with an ER Diagram.

Diagrams for Business Process Modeling

Task Communication Diagram

Used in Business Modeling to describe the chains of events and subtasks and their branching for a given task.


Task Specification Diagram

Used to further describe the attributes associated with tasks displayed in Task Communication Diagrams, such as performer, triggering conditions, constraints, goals, duration, etc.


Event Table

Event Table summarizes all events (messages, resources, timer events and complex events) defined and used anywhere in the Business Submodel.

Diagrams for behavior and process description

Process Diagram

Computer or Human Processes are displayed in the form of flowchart. Different operations are represented by different graphical symbols which can be formally interpreted.


Data Table

Contains all constants and variables used within a process diagram.


Specification Diagram

Specification Diagrams are used to represent call interfaces and parameters passed over the interfaces for procedures, functions and modules.


Imitation Diagram

Describes (in graphical or text form) simulation attributes (frequency of creation of Passive Objects, duration of processing and transfer time) in communication between Active Objects.

Diagrams for definition of User Interfaces

Screen Form

Definition of User Interfaces in quasi graphical form when designing software systems.


Graphical screen Form

Definition of Graphical User Interfaces with all standard elements of Windows interfaces (Dialogs, menus) and some extensions.


Report Form

Definition of Report Form for printing of reports, previewing on monitor or saving information in a file when designing software systems.

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 1st 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:

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:

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:

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:

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:

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:

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

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

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:

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:

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.

WP 4

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:

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:

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:

This model can be used for generation of:

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.


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.


[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://…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.