GRADE
Graphical Reengineering Analysis & Design Environment

Back to GRADE Modeler 4.0

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.

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.2 Process (behavioral) Modeling (PDs) *

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 *

• 1 Introduction
• 1.1 Principles of Modeling in GRADE

System modeling with GRADE includes the following main steps:

• Registration and hierarchical arrangement of the main objects of the system (described by object and class hierarchy);
• Description, simulation and reengineering of the business submodel (business processes and organization structure);
• Graphical representation of communications between main physical parts and functional objects of the system;
• Development of data model (structured description of messages and the databases);
• Creation of detailed functional specification of the system with a special accent on the IT system and its interfaces with end users and other components of the system;

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.

• 1.2 Summary of GRADE Diagrams

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.

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;
1. At least one example of each diagram type taken from the model;
1. Explanation of how this type of diagram has been used in our example.

• 2 Object Hierarchy and Classes
• 2.1 Registration of system objects

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:

• Active Objects can be considered as subsystems and processes of the system (organization units, people, equipment, computers, processes performed by them);
• Passive Objects are transferred among active objects or manipulated by them (documents, messages, files, diskettes, packages, etc.);
• Activities can be considered as functions of active objects and tasks performed by them (print a report, approve a document, calculate value, store in database);

• Datatypes describe data images and structures of passive objects (attributes of engine, amount of money, structure of data file).

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:

• Active Object XYZ Bank and Environment .. Consists of.. Applicant;
• Active Object Applicant .. Sends what .. Loan Application Form,
• Active Object Clerk .. Performs.. Procedure Approve Letter,
• Procedure Approve Letter .. Includes .. Read Application,
• Procedure Read Application .. Exports .. Loan Application Form,
• Passive Object Loan Approval .. Has as data image .. Loan Approval,
• Datatype Loan Approval .. Has as field .. RegNo, etc.

Figure 2 Main Objects of XYZ Bank

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

• 2.2 Tree of diagrams

• 2.3 Object Class Diagram (CL Diagram)

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:

• Object Class symbol (represented as a solid line rectangle). In this example gray shading is used to represent classes that correspond to active objects or performers of activities. The white background is used for classes of passive objects (data elements). Each Object class may have the following characteristics:

• Name of class, e.g. Officer;
• Free form textual comment;
• Stereotype of class, e.g. <<Clerk>> as a stereotype of Officer;
• Attributes, e.g. Maximum Loan as attribute of Officer;
• Methods, e.g. Determine Eligibility as operation to be performed by Officer;

• The classes are linked with the following types of relationships:

• Binary association between classes, e.g. Officer determines eligibility of Loan Application Form;
• Ternary (N-ary) relationship, e.g. answer – Applicant is receiver of answer, Loan Application form is referenced in answer and Letter is a written answer;

• Generalization (versus ‘is subclass of’), e.g. Signed Approval Letter is subclass of Letter or Letter is superclass of Signed Application Letter;
• Aggregation (versus ‘is part of’), e.g. XYZ Bank consists of Human Resource Department and Accounts Dept;

• Note symbol (solid line rectangle with one cut corner) represents comments associated with the objects of Class diagram. Notes are attached to the corresponding classes with an anchorline (dashed line between note symbol and class symbol).
• Free text or graphical comment may be used to emphasize or highlight certain parts of the diagram, e.g. the class Letter and its subclasses are enclosed in a gray shaded area in order to separate these elements from other classes.

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.

• 3 Diagrams describing structure and communications

• 3.1 Organization Diagram (ORG diagram)

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

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

The elements of ORG diagram can have the following attributes:

• name of element;
• number of instances (for multiple elements only);
• type:

• internal (represented as rectangle) or

• external (represented as dashed line rectangle);

• competence (skills or description of job);
• availability (time and dates, including weekdays, when the element is available as performer);
• cost per hour;
• efficiency level (productivity)
• name of employee (for single positions only);

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.

• 3.2 Communication Diagrams (CD diagrams)

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:

• processing represented by a rectangle;
• accumulation and storage of Transfer Objects represented by a parallelogram;

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.

• 3.3 Interface Tables (IT diagrams)

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:

• Channelline - Over what path something is sent. Channelline as a rule consists of 2 plug names: name of the sending plug (belongs to the sender) and name of receiving plug (belongs to the Active Object, which receives the message). The plug names are needed to describe more complex situations in message transmission, e.g. when several receivers are connected to the same sending plug then the sender can perform synchronous broadcasting.
• Datatype - specifies the datatype of the passive object being sent. This column can also be filled in with the name of a Passive Object which includes:
• name of Data (described as a Datatype which is relevant for development of Information system),
• name of Physical Objects (corresponds to real objects in the business area): packages of documents or other objects, forms, bills, etc.
• Transmission mode - how the object is sent, asynchronous or synchronous transmission modes; This column may also include information about the needed transfer time;

Figure 8 Interface Table 'XYZ Bank - Applicant'

• Frequency - show the unit of time and the average and maximum number of messages that will probably be transmitted via this channel;
• Sender - Name of the object sending the message;
• Receiver - Name of the object receiving the message;
• Actions taken by Receiver - this is a special variant of a comment where actions can be listed that are triggered at the recipient end on receipt of the message via the corresponding channel. These action names may be converted, e.g., into a sequence of procedure calls in an early version of the related PD diagram.

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:

• modeling of dynamic and reactive properties,
• system simulation,
• optimal implementation of the system and its database.

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 PT_i and one output plug table PT_o 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).

• 3.4 Access Tables (AT Diagrams)

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

• R - read access rights (Read)
• A - Add new instances to an entity (Add)
• U - Update existing entity instances (Update)
• D - Delete entity instances (Delete)
• G - General access rights (General)

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.

• 4 Diagrams for Data Modeling
• 4.1 Diagrams for Definition of Data Structure (DD)

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

• elementary (simple, atomic) datatypes, in which a single value is defined for each datatype; They include:
• predefined (standard) types, e.g. INTEGER, FLOAT, CHAR, STRING, BOOLEAN; The definition of predefined datatype can be supplemented by its value range, value set, pattern, length, alignment, etc.
• user-defined enumerated types , e.g. color = (red, blue) and
• time datatypes with numerous format defining facilities, including different formats for date and duration, conversion of week days, etc.
  The attributes of elementary datatypes are used for validation of values of data elements during data manipulation via PD, SF and RF.
• additional subdivided, structured datatypes. The structured datatypes in GRAPES/4GL encompass:
• arrays,
• records,
• variant records,
• sets and
• lists.

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.

• 4.2 Entity Relationship Diagrams (ER)

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:

• Entities - represent independent data groups to be stored in the associated database;
• Nested entities (e.g. Lawyer) - represent data groups that are not completely independent from other data groups and can be identified uniquely only with respect to the parent entity; Typical example - lines of a table (correspond to nested entities) included in a document (represented as parent entity);
• Subtype entities (1-nested entities) of independent entities - represent specialization of the parent entity, e.g. Programmer as a subtype of all positions of employees;

The description of entity includes:

• name of entity (data group);
• reference to datatype describing attributes of the entity;
• Primary key (a subset of fields of the entity datatype; it may include elementary datatypes only) which identifies uniquely every instance of the entity type;
• Maximum number of instances;
• Index fields (secondary keys) for the entity;
• Free text comments on entity.

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 or two role names; Role names must be unique if two entities are linked by more than one relationship.
• The cardinality for each side of the relationship; These can be described purely formally in min..max format, where min can be 0 or 1 and max 1 or n. Graphically, the cardinalities are represented in the “crow foot” notation devised by J. Martin.
• Foreign key; If one side of a relationship has the cardinality 0..1 or 1..1, the relevant entity can directly reference a specific instance of the other entity. In ER models, foreign keys are defined by the specification in the FK field name on the relevant side of the relationship.

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.

• 5 Diagrams for Modeling the Dynamics of a System

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

• Business Process Modeling (Business Submodel) described as sequences of Tasks (in Task Communication Diagrams) initiated by a certain combination of events, e.g. incoming Passive Object or time moment;
• Process Diagram (PD) describing the dynamic behavior of a separate Active Object in the form of a flowchart (GRAPES-86 approach);

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.

• 5.1 Business Process Modeling

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:

• by defining tasks (TSD diagrams) and then combining them into a business process or
• by direct drawing Business Process (TCD diagram). For each task the corresponding specification diagram and the event table entries will be created and synchronized automatically.
• 5.1.1 Task Specification Diagrams (TSD)

• Input events are depicted as arrows connecting possible neighboring tasks with the task body rectangle. The name of the input event is written near the arrow depicting it. The input events may be:
• generated regularly or randomly or
• received from another Task with or without a delay (transfer time);
• The task body is a rounded rectangle split into sections. Each section (except the top section) has a name separated from the contents of the section by a colon.
• Formally interpreted Task Attributes are:
• Name of Task and type (Transformation or Decision);
• Triggering Conditions section (describes exactly which combinations of the listed input events can trigger the task); The triggering condition is expressed as a logical expression composed from the names of input events;
• performer section lists the objects involved in the completion of the task. If the business model has no ORG diagram, then these objects may be real world objects (machines, people, sites, etc.). In the opposite case the objects listed in the performer section typically will be elements of ORG diagram (organization units, positions and resources). The task may be performed by different sets of objects; therefore, the possible performers in general are described by a logical expression with `&' and `|' connectors;
• Simulation attributes section describes attributes relevant to simulation of the task; It includes DURATION (the time necessary to complete the task), MAX Instances (maximum number of task instances that can be active simultaneously, Priority of the task (relevant when several tasks are waiting for the same performer), ATTRIBUTES (calculates value of attribute during task execution), ALTERNATIVE PROBABILITY subsection is relevant if several refinement alternatives (in the form of TCD diagrams) are provided for the given TSD diagram.

• The following Task Attributes are not interpreted formally:
• Informal description of Task;
• Objectives of the Task;
• Constraints for the task;
• Execution mode describes the way the task is going to be performed. The possible keywords here are manual (not automated), interactive (automated, via a dialog between the user and the information system), batch (automated, without the interaction of the user);
• The decision section is present only in the decision tasks (see Figure 13). It consists of one or more decision symbol connected to the task body by lines. Decisions depict different possible outcomes of the task. The identifier of the decision is written in the first line inside the decision symbol. In the second line, the field <probability> provides the probability of the decision. Groups of produced output events may be chosen according specified probabilities of Decisions;
• Output events are depicted as arrows leading to possible neighbors of the task. For transformation tasks, arrows start at the task body rectangle. For decision tasks, arrows start at the decision symbols. The name of the event is written near the arrow.
• 5.1.2 Task Communication Diagrams (TCD)

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.

• The internal task represents a task, which is part of the task being refined. The corresponding symbol is a rounded rectangle divided into two sections by a horizontal line and blue default color. The top section of the rectangle contains the name of the task (it is the same name, which will be used for the TSD diagram describing this task). The bottom section contains the contents of the performer section of the corresponding TSD diagram. The Internal task can be a transformation task or a decision task.
• The referenced task symbol is used to represent tasks described in another TCD diagram in the same business model. Referenced task symbols are used to show destination/origination of the events sent/received by the internal tasks but destined for/originating in some other TCD. The remote task appears as a dashed line double rectangle with a yellow default color (e.g. Process Payment in Figure 14);
• The external task symbol represents a task, which is not described in the considered business model. It is used to show the destination of events sent/received by the internal tasks but destined for/originating in the environment. An external task appears as a dashed line rectangle with red default color;
• An arrow in the TCD diagram represents the flow of events between the tasks. Near the arrow are written the names of events transmitted over it. An arrow can connect any two task symbols (for decision tasks, the arrow starts at the decision symbol). An exception is the timer event, for which the corresponding arrow starts in clock symbol and ends at the task, which receives the timer event.
• If the tasks access databases or other information sources (paper, cards, books, etc.,) then the database symbols (parallelograms) may be included in the TCD diagram;
• The functioning of Business Model can be described as follows. Tasks are initiated (triggered) by input events. Tasks produce output events (events on outgoing arrows). Tasks are performed by one or several performers (Active Objects). Branching is enabled by Decisions chosen with specified probabilities.

Simulation of Business Model:

• TCD can be used as a basis for the time and resource simulation of business processes;
• Simulation process can be animated, all simulation events can be collected in the Trace Browser;
• Results of simulation can be inspected via Trace Browser, summarized, represented in Tables and Charts and exported as ASCII files for further processing via spreadsheets or simulation tools;
• 5.1.3 Event Tables (ET)

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:

• Name of the input/ output Event;

• Category - indicator “Message/ Timer/ Resource/ Complex (any combination of the above);
• Datatype or Format of the Event;
• Persistence interval (for timer signals depicts how long time the timer signal waits in the input queue of task for other events of the triggering condition);
• Transfer time (depicts delay due to transfer of message or material to the next task);
• Non-formal Description of the Event.

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.

• 5.1.4 Event driven Process Chains (EPC)

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

• Events (six cornered boxes, default color – magenta),
• Tasks (rounded boxes, default color – green),
• Connectors to other EPCs (rounded box with arrow, default color – yellow, e.g. ‘Register Loan’) and
• Logical connectors (AND, OR, XOR) between tasks and events.

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

• 5.2 Process (behavioral) Modeling (PDs)

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 (PD) describe the main activities and their sequence for each Active Object; Process diagrams can represent the activities informally (using GRAPES-86 statements) and formally (using GRAPES/ 4GL statements).
• Data Tables (DT) and Specification Diagrams (SD) specify variables and their Datatypes within processes;
• Imitation Diagrams (ID) 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;
• Screen Forms (SF) and Report Forms (RF) specifying the end-user interfaces when modeling components of a software system.
• 5.2.1 Process diagrams (PD)

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:

• PROCESS - describes main activities of an active object with the same name; Process may be endlessly active (like the corresponding active object);
• PROCEDURE (including functions) - describe compactly in one diagram a subset of activities that may be called (performed by) from other processes or procedures;
• MODULE is used in modules describing a group of jointly used procedures;

Figure 17 Informal Process of Applicant

• MACRO describes a chain of activities with one start and one exit;

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

• All subtypes (except MACRO) begin with a START symbol, which has a single exit and may also contain a name.

Figure 18 Formal Procedure 'Determine Eligibility'

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

• Send/Receive statements (representing transmission of Passive Objects)
• Call Procedures (with or without parameters);
• A common database.

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

• 5.2.2 Data (Variable) Tables (DT)

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:

• VA/CO - indicator “Variable/Constant/ Based variable”;
• Name of the Variable/Constant;
• Datatype or Format of the Variable/Constant;
• Column Value may include also non-formal Description of the Variable/Constant.

Figure 19 Data Table for Procedure 'Determine Eligibility'

• 5.2.3 Specification diagrams (SD)

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:

• A procedure symbol that contains the name of the referenced procedure;
• Parameter symbols that each represent by rounded box a parameter of the procedure.
• Channel parameter symbols. These symbols represent channel parameters of the specified message type. Channel parameters can be used instead of channel or plug names in SEND and RECEIVE symbols within procedures.
• Parameter access paths. These are represented by continuous lines with circles, in the same way as database access paths. The parameter name appears above the line of the parameter access path.

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.

• 5.2.4 Imitation Diagrams (ID)

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:

• GENERATE new passive objects (this statement performs generation independent of the situation in the system);

• CREATE a new passive object (this statement performs creation according to the previous activity, e.g. receipt of a Passive object).

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:

• time interval between 2 sequentially generated passive objects;
• duration of processing and/or transmission of a passive object between active objects.
• 6 User Interfaces and Other Diagrams
• 6.1 Screen Forms (SF) and Report Forms (RF)

For the definition of user interfaces GRADE provides:

• Screen Form (SF) diagrams for definition of information exchange via monitor;

Figure 22 Screen Form with I/O fields

• Report Form (RF) diagrams for output of information to printer, preview on monitor or output into file.

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:

• Form layout created by graphical form painter (editor);
• References to manipulated datatypes;
• Form position and color section;

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.

• 6.2 Windows type Screen Forms (GF)

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

• Text fields,
• Input/ output fields,
• Listboxes,
• Comboboxes,
• Buttons,
• Subwindows,
• Vertical and horizontal scrollers for graphical selection of values,
• Frames and bitmaps,
• Groups of Radio buttons and Checkboxes.

Figure 23 Screen form in GUI style

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

• 6.3 Supplementary diagrams

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.

• 7 Integrity of GRADE Model
• 7.1 Diagram Tree and Links Between Diagrams

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 Object Oriented submodel, which is represented as a hierarchy of CL diagrams. This submodel may also serve as a starting point for the other two submodels, if they are going to be arranged hierarchically;
• The Business Submodel, which starts with a BM diagram as a formal place holder and contains one ORG diagram, one Event Table and an unlimited hierarchy of business processes (TCD diagrams);
• The Software System Model, which starts with a CD OBJECT diagram and may include process diagrams, data submodel and definition of user interfaces.

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:

• CLASSES (CL) diagrams for the Object Oriented submodel,
• TASK (TSD) diagrams for the Business Submodel and
• OBJECT (CD) diagrams for the System submodel.

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, PT_i/ PT_o - input and output plug tables, PD - procedures, DT - data tables).

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

• The physical structure of any object is described in terms of CD OBJECT diagrams. Alternatively the ORG diagram can be used. The refinement of the system can be continued by:
• decomposition in lower level CDs (see downwards from top level CD in Figure 24) and by Interface Tables describing communication between objects (see diagrams to the left from top level CD in Figure 24) or by
• business process description in terms of TSD and TCD Business Process diagrams or by
• switching to the description of behavior in terms of PD Process diagrams;
• The business processes of the system can be described in a separate subtree of TASK and TCD Business Process diagrams. Such business submodels can be subordinated to any CL Classes diagram. Thus several Business Submodels can be included in one GRADE model.
• The behavior of the object is described by PD PROCESS diagram with the same name and the subordinated SD PROCEDURE diagrams (see process ‘Human Res Dept’ in Figure 3 Hierarchy of Diagrams). The PD PROCESS can have references to other visible procedures, e.g. both ‘Human Res Dept’ and ‘Software Application’ can reuse the commonly visible procedure ‘Determine Eligibility’ (see Reusable Building Blocks in Figure 24).
• Data structures (DD diagrams) and databases (ER diagrams) used by active objects are subordinated to the corresponding CD Object diagram or CL Classes diagrams or BM diagrams. There are 2 data submodels in the model tree of XYZ Bank model. One of them is the global data model and it is subordinated to CD ‘XYZ Bank and Environment’ (see Figure 3). The other is local data model below CD ‘XYZ Bank’. In Figure 24 the data model is displayed as consisting of 2 parts -- Interface data and Process data. They actually are 2 different subsets of one global data model.

Figure 24 Links between GRADE diagrams

• The Event Table data and Interface data is the major part of data model, which is obtained by analysis of messages between tasks in Business submodel or from Interface Tables (see the links from TSD via ET and from CD via IT to the data model in Figure 25 System structuring tree’).
• The Process data is the data submodel that describes datatypes and variables during modeling of processes. The data elements in this phase should be obtained mostly by referencing to the earlier defined data elements from the ‘Interface Data’ submodel.

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.

• 7.2 Links Between Submodels

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:

• Data Dictionary including all datatypes mentioned in Interface Tables, DD diagrams, Data Tables and Process Diagrams;
• Persistent data model including all entities mentioned in databases and their datatypes;

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.