Graphical Reengineering Analysis & Design Environment



Publication 1


Diagrams in GRADE


Back to GRADE Modeler 4.0


Note on this series of Publications


This publication is the first in a series of short technical pieces on various aspects of GRADE. It is intended for those users or potential users who have seen GRADE, either in a demonstration setting, or in a seminar, and would like to obtain a deeper understanding of GRADE.

Because GRADE is such a broad and deep subject, each of these publications will focus on a particular aspect of GRADE, in this case diagrams. Other publications will focus on Languages used in GRADE, Alternative methods of Business and Process Modeling in GRADE, Simulation and Animation of Business Processes, Statistical Analysis of Simulation Results, Simulating the Performance of Software Systems in GRADE among others.



Table of Contents

1 Introduction *

1.1 Principles of Modeling in GRADE *

1.2 Summary of GRADE Diagrams *

2 Object Hierarchy and Classes *

2.1 Registration of system objects *

2.2 Tree of diagrams *

2.3 Object Class Diagram (CL Diagram) *

3 Diagrams describing structure and communications *

3.1 Organization Diagram (ORG diagram) *

3.2 Communication Diagrams (CD diagrams) *

3.3 Interface Tables (IT diagrams) *

3.4 Access Tables (AT Diagrams) *

4 Diagrams for Data Modeling *

4.1 Diagrams for Definition of Data Structure (DD) *

4.2 Entity Relationship Diagrams (ER) *

5 Diagrams for Modeling the Dynamics of a System *

5.1 Business Process Modeling *

5.1.1 Task Specification Diagrams (TSD) *

5.1.2 Task Communication Diagrams (TCD) *

5.1.3 Event Tables (ET) *

5.1.4 Event driven Process Chains (EPC) *

5.2 Process (behavioral) Modeling (PDs) *

5.2.1 Process diagrams (PD) *

5.2.2 Data (Variable) Tables (DT) *

5.2.3 Specification diagrams (SD) *

5.2.4 Imitation Diagrams (ID) *

6 User Interfaces and Other Diagrams *

6.1 Screen Forms (SF) and Report Forms (RF) *

6.2 Windows type Screen Forms (GF) *

6.3 Supplementary diagrams *

7 Integrity of GRADE Model *

7.1 Diagram Tree and Links Between Diagrams *

7.2 Links Between Submodels *


System modeling with GRADE includes the following main steps:

During these steps an integrated GRADE model is created. 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. The diagrams provide various views to the objects used within GRADE model. There are numerous converters between these model views, however, each object has a single point of definition in the repository.

The diagram types used within GRADE model are summarized in the table below. This does not reflect the sequence of model development and the diagrams in the table is arranged according to the system modeling aspect (structure, functions, behavior, data, user interfaces etc.).

GRADE tool itself is methodology independent and supports the creation of system model according virtually any methodology (procedural, data driven, structure driven or object oriented). However, some hints on the most effective system modeling framework with GRADE are given at the end of this paper.




Section, Page

Diagrams for declaration of objects and hierarchy

Object Tree

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

pg. *

Class Diagram

Represents hierarchy and associations between object classes according OMT/UML notation. Each class is associated with attributes and methods (operations).

pg. *

Diagram Tree

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

pg. *, 7.1,
pg. *

Diagrams for structure and communication modeling

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

pg. *


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.

pg. *


Interface Table

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

pg. *


Access Table

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

pg. *

Diagrams for data modeling

Data Diagrams

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

pg. *

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.

pg. *

Diagrams for Business Process Modeling

Task Communication Diagrams

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

pg. *

Task Specification Diagrams

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

pg. *


Event Table

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

pg. *


Event driven Process Chain

Depicts chains of Events, Tasks and connectors (AND, OR, XOR) between them. Is an alternative form of TCD.

pg. *

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 that can be formally interpreted.

pg. *

Data Table

Contains all constants and variables used within a process diagram.

pg. *


Specification Diagrams

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

pg. *


Imitation Diagrams

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.

pg. *

Diagrams for definition of User Interfaces

Screen Form

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

pg. *

Graphical screen Forms

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

pg. *


Report Form

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

pg. *

Supplementary Diagrams


Comments can be attached to each diagram, edited either in GRADE or with external text processors, drawing tools, etc.

pg. *

Default Diagram

Defines default settings for the I/O operations. They prevent GRADE user from explicit definition of settings in each diagram.

pg. *

To illustrate how GRADE diagrams are used, we have prepared a simple model, where an employer (XYZ Bank) has a policy of granting loans to employees under certain conditions, that can be used to purchase a home. Sections devoted to each diagram will contain the following:

  1. Formal description of the diagram;
  2. At least one example of each diagram type taken from the model;
  3. Explanation of how this type of diagram has been used in our example.

The building of diagrams can be started immediately from the beginning of project. However, before the building 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 main objects used for system description are depicted in Figure 1.

The semantical meaning of the objects is as follows:

Figure 1 Objects and relationships between them

The main objects found in our target system XYZ Bank are displayed in Figure 2 Main Objects of XYZ Bank.

The types of objects are displayed by small icons and acronyms AO, PO, PR and TY. The view on the object hierarchy is customized by selecting types of visible and hidden objects and relationships. The description fragments in can be read as follows:

Figure 2 Main Objects of XYZ Bank

The lines marked with ‘+’ can be expanded to reveal more details about the corresponding object.


The preliminary description of system in terms of objects can be used to generate draft versions of GRADE diagrams. A set of joined and hierarchically arranged diagrams constitutes GRADE model and is represented as a model tree (see Figure 3 Hierarchy of Diagrams).

The model tree includes semantically meaningful names of diagrams and abbreviated names of diagram types. A more detailed explanation on the structure of model tree and links between separate submodels and diagrams will be given at the end of this overview. For the time being we can consider the model tree as a table of contents of all diagrams developed for the model ‘XYZ Bank’.

Figure 3 Hierarchy of Diagrams

According Object Oriented modeling approach the development of GRADE model can be started with Class Diagram (CL CLASSES). GRADE supports representation of object classes according OMT (Object Modeling Technique) / UML (Unified Modeling Language) standards.

An example of CL diagram for the XYZ Bank is depicted in the figure below.

Object Class diagram may include the following elements:

Figure 4 Class Diagram of XYZ Bank

The cardinalities of these relationships are represented according James Martin “crowfoot” notation and described with the role names.

GRADE model may have several subordinated CL diagrams. The contents of CL diagrams may be converted automatically to fragments of data model and Organization diagram.

ORG diagram and CD (Communication diagrams) both describe the static structure of a model. They are used to represent both the division of Active Objects into smaller subobjects and the communication between them. The starting point of structure modeling in a business submodel as an ORG diagram. The objects of ORG diagram can be converted to CD diagram and vice versa.

The organizational structure (Organization chart) can be described compactly in terms of ORG diagram. ORG diagrams are represented as trees with the following elements:

Single element

Multiple element


Organization Unit (e.g. Office, department, production line)

Position (e.g. Secretary, Chief, Programmer, etc.)

Resource (e.g. a car, PC, software module, etc.)

Figure 5 depicts an example of more complex ORG diagram for the XYZ bank.

The elements of ORG diagram can have the following attributes:

Figure 5 Example of ORG diagram


GRADE Modeler and Simulator may use all of these attributes formally. Besides a free text comment can also be included in the elements of ORG diagram. The ORG diagram can be converted automatically to/ from hierarchy of Active Objects of Registrator and CD diagram hierarchy.

There are two types of objects, which are distinguished by the text in their object symbol: simple objects and object type instances (typed objects). A database symbol is available to represent a passive database. The object symbol can be refined by subordinate CD or PD diagrams. In the first case, it is called a structured object; in the second case, it is called a process object.

The name of the refining CD or PD diagram is always identical to the name of the object that represents it. The symbol for an internal communication path (Figure 6 XYZ Bank and Environment (Top Level CD)) links two object symbols in the same CD diagram. It signifies that messages are transmitted from one object to another in the specified direction.

Figure 6 XYZ Bank and Environment (Top Level CD)

The communication path has a name that must be unique within that CD diagram. The symbol for the internal communication path is refined by an IT diagram (an interface table) of the same name. This diagram depicts the channels of the communication path and lists the datatype of the messages transmitted via the respective channel.

Figure 6 is a CD diagram that shows the Target system (XYZ Bank) and objects from environment (Applicant).

The object XYZ Bank contains all the elements of the system to be described, and is in the top level CD. Applicant is a non-divisible object, and has Process Diagram, producing input messages for the target system.

Figure 7 CD Diagram for XYZ Bank, is a subordinate diagram which refines the structure of the upper level object XYZ Bank. In it appear those objects such as departments and systems, which participate in processes or perform tasks which have to be defined in order to get a complete view of the system. Objects represented in this Communication Diagram can perform:

The object ‘Software Application’ is further described in a Process Diagram, which describes the operation of a software application that supports the loan application process. The objects ‘Human Res Dept’ and ‘Accounts Dept’ are further divisible into additional CD diagrams.

The object Database is further defined in an ER Diagram, and the structure of the data that it contains is detailed in DD diagrams.

This diagram includes also several External Communication Paths represented with dotted lines. They show that Objects ‘Human Res Dept’ sends and receives information to/ from other objects outside this diagram and ‘Accounts Dept’ only sends transfer objects externally. Each external communication path is also associated with an Interface Table. In this IT we can find the invisible sender/ receiver of messages.

The Database is accessible from object ‘Software Application’ via the Access Path. In general several databases are permitted within one GRADE model. Each database must be associated to one ER model. The same or several data models can be defined and referenced within one GRADE model.

Figure 7 CD Diagram for XYZ Bank

The small circles at each end of the access path indicate that ‘Software Application’ has read and write access rights. The access rights can be limited to read-only or write-only for the whole access path. Each Access Path can be associated with Access Table.

Interface tables are always linked to a specific communication path in a CD diagram and describe the transmitted datatype and transmission mode for each of its channels. In general, the IT diagram depicts the following:

Figure 8 Interface Table 'XYZ Bank - Applicant'


The above mentioned numeric attributes of Passive Objects extend the scope of GRADE as opposed to traditional CASE methodologies (Yourdon, Orr, Martin, Gane et al.) to CAS/SE (Computer Aided System and Software Engineering) of large systems (Gobins). CAS/SE enables:

Figure 8 is a typical example of an IT diagram, which depicts the interface from XYZ Bank to Applicant.

Communication from one active object to all other receivers can be viewed in Plug Tables. There is one input plug table PTi and one output plug table PTo for each CD OBJECT. They show plug names and the corresponding datatypes transmitted via these plugs. Communication between all active objects can be viewed in Global IT. Its structure is similar to ordinary IT (see Figure 8).

Access Tables describe the access path between an Active Object in a CD diagram and a database. Each access table describes an (internal or external) access path that has the same name as the table.

The access table refines the access path to a database by assigning specific access rights to its entities. The following types of access rights are available:

Figure 9 AT Diagram Software Application to Database

Figure 9 depicts the access path between Software Application and Database.

In this case the Application is the data contained in the application form that Applicant has filled out to obtain a loan, position is Applicant's title as shown in personnel records and property is information regarding the home that Applicant has purchased with the proceeds of the loan.

The data model of the system includes a structured description of a Passive Objects in the form of Datatype hierarchy Diagrams (DD). Figure 10 includes an example of a DD diagram for ‘Loan Application Form’.

In GRAPES/4GL the datatypes are divided into 2 groups;

All of these can be reused and referenced in multi-level nested structures of user defined datatypes. For example, the datatype ‘Address’ is defined once as a part of the record substructure ‘Property’ and reused one more time as part of record ‘Lawyer’.

Figure 10 Data Structure of 'Loan Application Form'

Each Datatype or structure of datatypes should be defined only once. GRADE supports reusability of data definitions according multilevel visibility laws. Multiple definitions of one datatype within one visibility area are forbidden. Within different visibility areas multiple definitions of a datatype with the same name means definition of 2 different types and in each model point, one of them is dominating and concealing the other.

An ER model is made up of entities (rectangles with rounded corners) and relationships (relationship lines). ER Diagrams represent relationships between entity types (data groups of specific structure). ER Diagrams must be associated with a Database symbol from a Communication Diagram. Like all other GRADE Diagrams ER Diagrams can also be used in formal and informal mode.

Figure 11 shows all of the elements of our target system in informal Entity Relationship diagram form. For the sake of clarity we have grouped some of the objects into shaded boxes.


Figure 11 Informal ER Diagram of XYZ Bank


An example of a formal ER diagram is displayed in Figure 12. This diagram displays contents of the Database accessible by ‘Software Application’.

Each entity symbol also defines a record variable whose name is identical to the entity name. This variable can be referenced directly in data manipulation statements and assumes the values of the currently active entity class instance. In GRADE the following subtypes of entities can be used:

The description of entity includes:

Figure 12 Formal ER Diagram for Database

The interdependencies between the entities are called relationships. GRADE supports binary relationships without attributes. A relationship links two entities, which can also be identical. Relationships with attributes can be modeled by introducing new entities with relationships to the existing ones.

To define a relationship, the following specifications are necessary in addition to the names of the two entities concerned:

One GRADE model may have 2 data models - a conceptual and implementation model. The conceptual data model can be created by the Data Analysis Facility during the initial analysis of structures of passive objects, documents and messages registered in Interface Tables and described by DD diagrams. The implementation data model is created later mainly by cutting and pasting fragments of the conceptual model. It is used for the purposes of data manipulation and implementation of database. Relational Database Tables are generated from graphical specification of the implementation ER diagram.

The following two aspects are available in GRADE for modeling of dynamics of the system:

The principal difference between the behavioral description using PD approach and the GRADE-Business Modeling approach is the following.

In PD, behavior is described by decomposing the whole system into separate performers (down to the separate "clerk" or separate "computer," etc.); then, for each elementary performer, its behavior is described by means of a PD diagram. The behavioral descriptions of the separate components, together with the set of CD diagrams, provides the behavioral description of the whole system. Such a description of the system can be regarded as an implementation-oriented description.

On the other hand, when we start to design an information system, one of our first objectives is to describe the tasks, which the system will have to perform (and it is the goal of the following development phases to decide which performers will perform exactly which task). The business modeling approach calls for describing the tasks, which the system will have to perform and then refining these tasks into subtasks by using special TCD Business Process diagrams.

Business modeling may be carried out autonomously without the use of PD diagrams at all, in which case the performers will be machines, people, sites, etc. If the business modeling is combined with PD, then in parallel with the description of the business model of the system, we have to decompose the whole system into performers by using ORG or CD diagrams. Each subtask has to be assigned a performer. The approach used determines in which sequence the business model description of the system is developed and the corresponding structuring of the system in CD diagrams. GRADE methodology suggests to start with business modeling (TCD Business Process) and to switch over to more detailed behavioral aspects (CD/ PD) in the implementation phase of the project.

Business Process modeling in GRADE is based on TCD (Task Communication Diagrams), TSD (Task Specification Diagrams) and the Global Event Table, which is largely generated from them. You can start business submodel in 2 ways:

Each TSD represents a detailed description of one Task. It includes the following parts:

Figure 13 TSD 'Discuss Loan'

TCD diagrams refine and graphically display the tasks already described by the higher level TSD diagram. The TCD diagram shows the chain of events and the subtasks of which the refined tasks consist. Several TCD diagrams, in which case these TCD diagrams are considered alternative refinements of the original task, can refine the same task.

TCD diagram includes the following symbols:

Figure 14 TCD Application for Loan

Simulation of Business Model:

The event table describes the events appearing in the TSD and TCD diagrams. Each business model contains only one event table, which in the model tree is located at the same level as the topmost TSD diagram. Each Event Table contains:

Figure 15 Event Table

The Event Table summarizes all events defined and used anywhere in the Business Submodel. The Event Table is created and updated automatically during the definition of TCD and/or TSD. The information in Event Table is overlapping considerably with Interface tables of the corresponding Active Objects.

Each Business Process Model starts with a BM diagram (formal placeholder of other business model diagrams) with associated ORG and ET Diagrams and is subordinated to an Active Object (CD). For one system there may be several business submodels subordinated to the same or several Active Objects. Further refinement of a Task is carried out in several subordinated levels of TCD and TCD Diagrams or in associated Process Diagrams.

Tasks in different TCDs can communicate and reuse the same Tasks repeatedly.

EPC diagrams are integral part of GRADE V 2.1. EPC (see figure 15) is an alternative form of TCD and depicts chains of:

Figure 16 Event driven Process Chain

Semantically this EPC diagram displays the process ‘Application for Loan’ which is also represented in Figure 14 as a TCD.

Process Diagrams (PD) describe the dynamic behavior of the whole system or one particular Active Object. Thus everything described within one PD will be performed by just one active object which is the owner of this process. Figure 17 Informal Process of Applicant is an example of an informal PD.

The following diagrams and tables are used in GRADE for modeling of processes:

Process diagrams describe the process behavior in a similar way to flow diagrams but differ in that they are structured. Process diagrams are divided into five subtypes:



Figure 17 Informal Process of Applicant

All subtypes of PD have the same flowchart-based syntax. Different operations are represented by different graphical symbols. Process Diagrams use the following symbols.

Figure 18 Formal Procedure 'Determine Eligibility'


  • The communication between processes starts with a SEND symbol. There are several subtypes of SEND symbol which all have similar graphical outline:
    • asynchronous SEND of message ‘Loan Application Form‘ via communication path and plug to ‘Human Res Dept’ is the third symbol in Applicant’s process (Figure 17);
    • Synchronous transmission is represented by a similar symbol called SEND_WAIT;
    • Output of information via Screen Form (to Monitor) or Report Form (to printer, monitor or file) is included in formal procedure Determine Eligibility (Figure 18);

  • The information can be received via RECEIVE statement which has the following versions:
    • RECEIVE information via communication path and plug ‘from Officer’ from another process object Officer and store it in a variable ‘Rejection’ (see the 4th statement on the left in PD Applicant, Figure 17);
    • Input information into variable ‘Loan Application Form’ via screen form ‘Application Input’ (see the 1st statement in PD ‘Determine Eligibility’, Figure 18);
  • Textual description of activities, formal assignment of values and data manipulation are depicted in a rectangular box (see 5th statement on the left in Applicant’s process or 2nd statement in the PD ‘Determine Eligibility’ for data manipulation);

  • Procedure calls are represented by rectangles with double lines at either side and have one exit (see ‘Prepare Repayment Schedule’ in PD ‘Determine Eligibility’). Call symbols contain the name of the calling procedure and, where applicable, a list of the assignments of the current parameters to the formal parameters;

  • Decision with 2 exit branches (DECISION) and multiple exits (CASE) can be used both in formal (see PD ‘Determine Eligibility’) and informal (see Applicant’s process) way; The condition inside the Decision symbol must provide mutually exclusive values for each exit.

  • The control flow of a process diagram always ends in a STOP symbol represented as a cross with no exits (see Figure 17 Informal Process of Applicant).
  • Other procedures end in an END symbol (see Figure 18 Formal Procedure 'Determine Eligibility'). After this symbol control is returned to the higher level PD which called this procedure.

Each Process Diagram is subordinated to an Active Object or another PD. Information Exchange between Processes can be specified by:

In our example ‘XYZ Bank’ the informal PD ‘Applicant’ (Figure 17) describes the activities of Applicant as follows. After sending of ‘Loan Application Form’ to ‘Human Res Dept’ of the bank, the Applicant waits for 2 possible answers. If the ‘Rejection’ from Officer arrives he can ‘wait or change application’ and send it again. If the loan is approved he will perform 2 types of activities in parallel -- receive 5 payments and receive deduced salary until loan is paid off. When both of them are completed the process of ‘Applicant’ stops because each person is allowed to submit an ‘application for loan’ only once.

The formal procedure ‘Determine Eligibility’ in Figure 18 can be used for prototyping and code generation. It starts with input of ‘Loan Application Form’ into corresponding variable via screen form. Then the information is added to the database. The succeeding 2 decision statements check the tenure of applicant and compare the amount of loan with his salary. If both conditions are TRUE then the subprocedures ‘Prepare Approval Letter’ and ‘Prepare Repayment Schedule’ are called and executed and the monthly salary after deduction is displayed. If any of the conditions is FALSE then the applicant will receive rejection via procedure ‘Send Rejection’.

In GRADE, variables can be defined for processes, procedures and modules. They are declared in data tables (diagram type DT); these consist of lines, with each line describing a variable or constant (see Figure 19 Data Table for Procedure 'Determine Eligibility').

The four columns of a table have the following headers:

Figure 19 Data Table for Procedure 'Determine Eligibility'

Specification diagrams are used in GRADE to describe both the external interfaces of procedures and functions, and also modules. This is why this diagram type has two subtypes: SD PROCEDURE and SD MODULE.

Figure 20 Specification Diagram SD PROCEDURE

SD PROCEDURE describes the interface of a procedure by the procedure name as well as by the names and types of its formal parameters. Both SD and PD for a procedure have the same name (the procedure name).

A SD PROCEDURE diagram can contain the following symbols:

SD MODULE diagrams represent collections of procedures, functions, datatypes, variables, constants and initialization routines. The main purpose of modules is to isolate functional units of a specific object or operation so that they can be re-used. All components of a module are subordinate to SD MODULE diagram which serves as an export list for the module. Only the components featured in this list are visible outside the module. Graphical symbols of this diagram are similar to SD PROCEDURE.

Figure 21 Imitation Diagram for 'Human Res Dept'

Imitation diagrams describe the numeric attributes of CD elements needed for time simulation of communications between active objects (see Figure 21). The principles of CD simulation are as follows. Some Active Objects generate Passive Objects (datatypes) with a certain frequency. The delay between 2 subsequently generated objects can be constant or randomly distributed (with normal, uniform or exponential distributions). The generated objects can be processed and/or transmitted via Communication Paths to other Active Objects. Upon receiving Passive Objects the receivers may continue processing and transmission of the same objects further (until they are destroyed, i.e. expelled out of the model) or create new passive objects in react statements after receive.

Most of the graphical symbols in ID diagrams are similar to those of PD diagrams. There are, however, 2 additional symbols:

The ID diagrams consist of independent fragments starting with Generate or Receive statement. They depict the sequence of further activities as well as time attributes. The time attributes of simulation include:

For the definition of user interfaces GRADE provides:


Figure 22 Screen Form with I/O fields

Screen Form diagrams work on a principle of form generators. They are based on datatype diagrams and support all types of input/output operations, including input, modification and output of data, selection from constant and variable item list.

Each SF has:

Input fields of SF can be associated with validation expressions and procedures, default values, on-line comments, help and error messages, etc. All field attributes are displayed for viewing and editing below the graphical layout in textual form.

GRADE V.2.0 has a graphical screen form editor for quasi-graphical forms. An example of Input/output form ‘Application Input’ is depicted in Figure 22. The Report Forms have similar structure - with graphically represented layout of fields and groups of fields in the upper part of diagram and textual description of field attributes below.

GRADE V.2.1 has graphical screen forms with the following GUI (graphical user interface) elements (see Figure 23 Screen form in GUI style):

Figure 23 Screen form in GUI style

Input/ Output via SF/ RF is possible also directly - without an explicitly defined form.

Each diagram has a supplementary comment (CM) diagram. This provides a possibility to add textual comments to each main diagram. The comments can be edited with a built-in editor or can be linked with any external text editor in MS Windows or DOS environment.

A diagram tree may also include a default diagram. DF diagrams control screen form attributes and logical key names. DF diagrams are subordinate to communication diagrams. The visibility rules determine which default diagram will be actually used in each branch of the model tree.

The hierarchy of diagrams is represented as a tree of diagrams. For each GRADE model there is one main hierarchy of diagrams. This hierarchy may include any of the following submodels:

The topmost object in each model is the Classes Diagram. This diagram may have subordinate CL diagrams or it can have a subordinate Business Model (see the branch starting with BM diagram) or System Submodel (see the branch starting with the top level CD diagram XYZ Bank and Environment).

The backbone of the tree is:

They depict the physical structure and main processes of the system under consideration. The main diagrams of the tree are linked with connecting line on the left-hand side. The main diagrams can have associated diagrams. They are in the same line on the left (CM - comment diagram) or on the right (e.g. ORG diagrams, TCD Business Process Diagram, PTi/ PTo - input and output plug tables, PD - procedures, DT - data tables).

The active objects in GRADE can be described from 4 different aspects.

Figure 24 Links between GRADE diagrams

The links between diagrams in Figure 24 are shown by lines with circles in both ends. The gray circles depict the source diagrams. The black circles depict the target (subordinated) diagrams.

A simplified view on links between diagram types and system structuring forms is depicted in Figure 25. The class hierarchy may be a starting point for model development in OO style. The CL diagrams can be converted to fragments of business model and data model.

The links between the data model and the physical model (CD) are maintained through Interface Tables (common Datatypes). The links between the data model and the functional model (PD) are maintained through Data Tables (variables linked with datatypes).

Input output fields of screen forms are linked both with datatype definitions (type reference to DD) and with variables (via corresponding statement in PD for data Input/ output through SF.

Business models (TCD diagrams) are linked with behavioral models (PD) via a special PD associated to each TSD diagram or via the subordination of the TSD under a particular CD or PD object.

The Data Model is shown as consisting of 2 parts:

The Functional model includes Business Process submodel (TCDs on upper levels of detail) and behavioral model (PDs) describing dynamics of the system in more details. Both parts of functional model are linked to the same data model, which is created by analysis of Interface Data.

Figure 25 System structuring tree

The sequence of development can be adjusted to user needs. Although the recommended sequence of GRADE diagram development is object driven top down, the tool can be used to develop GRADE model according virtually any other style, e.g. you can follow data driven approach, object oriented approach, procedural approach bottom-up, etc.