SYNON Training material

Prepared by Arnab Ghosh

http://www.cognizant.com

What is SYNON

SYNON (COOL:2E) is an application development tool that allows us to design, develop, implement, and maintain applications software more efficiently, more rigorously, and more effectively than third generation methods permit. COOL:2E incorporates a number of industry standard methodologies in application development such as entity relationship modeling and object based design. SYNON (Cool 2E) is a case tool which generates code e.g. RPG, COBOL, C, VB.

Advantages of SYNON

Changes to the specification can be applied automatically throughout the application design.
Improvements or changes to the implementation can be made independently of the specification. The same design can be used to implement applications for several different operating systems and environments.

Methodology

Entity Relationship Diagram

Process Requirements

SYNON /2E
Data Model Access Path Functions Device Design Generate SYNON 2/E Application Design Model Documentation
4

Introduction To SYNON

Introductory Concepts

What is This Course all about ? How does Synon fit into the Application development process?

What kind of a tool is Synon 2E ?

What is Data modeling?

Evolution of Programming Language

1GL machine language instructions, often written in hexadecimal or octal form.

2GL Assembler, alphabetic abbreviations for group of machines

3GL High Level Languages. I/O Operation, logical construct, data type.

4GL High Level Language, simplify the coding process, still syntactical.

CASE Computer Aided Software Engineering - Tools

Advantage of CASE Tool

Modeling

Reducing the possibility of design Errors Avoiding Coding Errors Eliminating repetitive Processes Managing Standards

Data

Process

Design

Prototype

Generation

Waterfall Method

Feasibility

Requirement

Maintenance

Analysis/Design

Waterfall

Documentation

Coding

Testing

Disadvantage of Waterfall Method

Users receive applications long after they establish the initial need. Software updates are difficult to implement and are not cost effective. The later you make a change in the development cycle, the more expensive it becomes.

Post implementations maintenance is lengthy and expensive as well as risky. Changes to existing code are often not well documented leaving more room for error.

10

Rapid prototype Model

Analyze

Construct

Prototype

Design

Deploy

11

Advantage of SYNON/RPM

Reduced software development timeline Increased user satisfaction Improved maintenance timeline Higher Quality applications with error free code Reduced maintenance costs SYNON 2E enforced application standards Improve accuracy of documentations Future Proof applications that are reusable Platform independent modules Smaller development teams for higher productivity

12

Data Modeling

13

Introductory Concepts

What is Data Model

What are the different type of Files?

What are the different type of relations?

14

Data Modeling Definition

A data model is a structured description of a set of data and its relationships which we use to represent the business of an organization. Data modeling shows how things (entities) are related and interact with each

other.

SYNON takes a data-driven approach to data modeling. It uses the entityrelation (E-R) modeling method. An E-R model lists the significant business objects of an organization and the relationships between these objects. The approach is to translate the ER Diagram to COOL:2E relation.

15

Steps to translate ER to COOL:2E relation

Identify application Entity. An entity is a thing or object of significance for which we need to gather and store information. Identify Business Relationship between Entities. Identify the Attributes for each Entity. An attribute is any detail that serves to qualify, identify, classify, quantify, or express the state of an entity. An attribute can also be any description of a thing of significance. Identify Unique Identifiers for the Entities. The Unique Identifier is also known as primary key. Identify Foreign Key. Non-key attributes of an entity that are primary keys of another entity are known as foreign keys.

Normalize the Entities.

16

Example

Entity

Attribute

CUSTOMER MASTER

Customer ID
Customer Name

Primary Key

ITEM MASTER

Item ID Item Description

Item Price
ORDER HEADER Order Number Customer ID Order Total Amount

ORDER DETAIL

Order Number
Line Number Item ID Foreign Key

17

File Type

When defining a file we need to define the file type which is actually determined by the nature of the fields. Database File

Capture File (CPT) These are used as transaction file. Ex Order Header file. Reference File (REF) These are master file. Ex Customer Master file.

Non Database File

Structure File (STR) These dont contain any data. These files are included by other files as a source of common defined fields.

18

COOL:2E Relations

In SYNON: entity means file and attributes means fields. The relation can be established on file <> file or file <> field.

The relations fall into Three categories: File Definition Defined As

File to Field

Known By
Has Qualified By

File to File

Owned By

Refers To
Extended By Includes
19

Relation Defined As

Defined As - The Defined as relation declares that a file exists. SYNON creates the relation automatically when we specify any of its attributes.
HOSPITAL

Hospital

Defined As

Hospital

WARD

Ward

Defined As

Ward

PATIENT

Patient

Defined As

Patient

20

Relation Known by

Known by - Declares a field that is a primary key.

HOSPITAL
Hospital code K

Hospital Hospital

Defined As Known by

Hospital Hospital Code

WARD
Ward code K

Ward Ward

Defined As Known by

Ward Ward Code

PATIENT
Patient code K

Patient Patient

Defined As Known by

Patient Patient Code

21

Relation Has

Has - Declares a non-key fields (attributes) of a file. This is an optional relationship.

HOSPITAL
Hospital code Hospital Name K

Hospital Hospital Hospital Ward Ward Ward

Defined As Known by Has Defined As Known by Has

Hospital Hospital Code Hospital Name Ward Ward Code Ward Name

WARD
Ward code Ward Name K

PATIENT
Patient code Patient Name Patient Address K

Patient Patient Patient Patient

Defined As Known by Has Has

Patient Patient Code Patient Name Patient Address

22

Relation Owned by

Owned by - Specifies a relationship between two files. The primary key of the owning file becomes part of the primary key of the owned file. This specify, a record in the owned file cannot exist without the corresponding record already

in existence on the owning file.

HOSPITAL
Hospital code Hospital Name K

Hospital Hospital Hospital Ward Ward Ward Ward Patient Patient Patient Patient

Defined As Known by Has Defined As Owned by Known by Has Defined As Known by Has Has

Hospital Hospital Code Hospital Name Ward Hospital Ward Code Ward Name Patient Patient Code Patient Name Patient Address

WARD
Hospital code Ward code Ward Name K K

PATIENT
Patient code Patient Name Patient Address K

23

Relation Refers to

Refers to - Specifies a relationship between two independent files. The key fields of the referenced file gets included as a part of the non key fields of the referring file. These are the foreign keys.

HOSPITAL
Hospital code Hospital Name K

Hospital Hospital Hospital Ward Ward Ward Ward Patient Patient Patient Patient Patient

Defined As Known by Has Defined As Owned by Known by Has Defined As Known by Refers to Has Has

Hospital Hospital Code Hospital Name Ward Hospital Ward Code Ward Name Patient Patient Code Ward Patient Name Patient Address
24

WARD
Hospital code Ward code Ward Name K K

PATIENT
Patient code Hospital Code Ward Code Patient Name Patient Address K FK FK

Relation Qualified by

Qualified by The qualified by relation is a file to field relation. It resembles the known by relation in that a key is placed on the file but differs in that it does not require an exact match to its key. Selection is based on value that is closest to the key value.

For example if in an Item master, the item price changes based on date; we can create a Product Price file. We also need to mention the *PREVIOUS or *NEXT as the selection type. The file can be: Code 123 123 123 Date 010106 070106 010107 Price $100.00 $110.00 $125.00

Product Price Product Price Product Price

Known by Product Code Has Product Price Qualified by Effective Date

For a product 123 on say November 2006 the price will be $110.00

25

Relation Extended by

Extended by This is an optional one to one file relation. Two main reasons for using Extended by relations are:

Save storage space separately for a set of optional fields. Avoid recompiling while adding new set of fields to an existing file.

CUSTOMER
Customer Code Customer Name Customer Address

Most customers are normal customers and say 20% of them are international. Fields required for the international customers can be separated as a different file. The original Customer file can then be extended by Export Details file.

EXPORT DETAILS
Withholding tax Preferred Carrier Time Zone

Customer

Extended by

Export Details Customer

Export Details Owned by

26

Relation - Includes

Includes Specifies all the fields from the included file to be as the non key filed in the including file.
There are certain fields those are common to different files. For example Date stamp, Time Stamp, User ID. Normally we can create a file with these three

fields say as Audit Stamp. If Order Header File and Customer Master File both need the Audit Stamp; we need to specify the relation accordingly.
Order Header Customer Master Refers to Refers to Audit Stamp Audit Stamp

This doesnt contain any record. This works as a data structure included in different file.

27

Involution

In addition to all the relations described above, a file can reference itself. This is called involution or self referencing relation. Foe example if we think of an employee database with the employee name, DOB, DOJ, Address, Project,

YOE, Manager, Designation etc. The manager himself is an employee of the organization. So the manager will also have a record for his own in the employee file.

If there are more than one Refers to relation, we can identify them by using

extended relations. Taking a plus symbol in to the relation arm will extend the relation for For field and Sharing Field.

Employee

Employee Manager

Refers To

Employee

28

Virtual Field

A virtual field is a field which is logically present in any file but not physically. These are created to reduce data redundancy. In a file to tile relation Refers To; only the key fields from the referenced file

become a part of the referencing file. But to make a non-key filed as a part of
another file, we need to use virtual field.

We need to take a V against the Patient Refers to Ward condition and select the Ward Name field by + as a virtual field.
WARD
Ward code Ward Name K

Ward Ward Ward

Defined As Known by Has

Ward Ward Code Ward Name

PATIENT
Patient code Ward Code Patient Name Patient Address Ward Name K FK V

Patient Patient Patient Patient Patient

Defined As Known by Refers to Has Has

Patient Patient Code Ward Patient Name Patient Address

29

Field Sequencing

COOL/2E resolves the relations in the following order. Owned By > Known By > Refers To > Has Sequencing become important when we do an involution and with virtual field.

While trying to resolve for the virtual filed; the process stops when it gets the involution. Now, if we dont sequence the fields, the virtual field entry will come after the involution statement and hence COOL/2E will not reach to the field. So COOL/2E will not be able to create the virtual field.

30

Access Path

31

What?

What is Data Model

What are the different type of Files?

What are the different type of relations?

32

Access Path Definition

Access path controls how the data is presented to the programs (functions) that manipulate or update

the data. This determines:

File

Which records will be selected. The order of retrieval Available fields

Access Path

Function

33

Types of Access Path

SYNON provides six types of access paths

Physical Access Path (PHY) Update Access Path (UPD) Retrieve Access Path (RTV) PHY Physical File

UPD
Re sequence Access Path (RSQ) Query Access Path (QRY) Span Access Path (SPN) RTV RSQ QRY SPN Logical File

34

Physical Access Path

A physical access path defines the address of all data stored physically within a file. There can be only one physical file per data model file. SYNON/2E automatically creates this access path when we declare the file in data modeling. This doesnt have any key. The data is stored on arrival sequence basis.

35

Update Access Path

An Update Access Path specifies a view of the file which we need to use to perform update on the file. The file have the key sequence as mentioned as known by or Owned by.

These keys cant be altered.

SYNON/2E automatically creates this access path when we declare the file in data modeling.

36

Retrieval Access Path

The Retrieval Access Path specifies the view of the data which SYNON/2E generated programs use to retrieve records from a file. SYNON/2E automatically creates this access path when we declare the file in

data modeling.

We cant alter the key sequence. A file will have at least one or can have more than one Retrieval Access Path.

The access path can contain virtual fields.

This default access path contains all the fields from the data base.

37

Re-sequence Access Path

A Re-sequence access path specifies the order of the records retrieved from a file using an alternative key order. It includes all the fields from the file by default. A file can have several Re-sequence access path.

38

Span Access Path

A Span Access Path connects the formats (header and detail) from two SYNON/2E files with a common partial key. This spans two related files to combine data to a single view. This must be explicitly created. Keys can be overridden. Allow virtual fields to be specified across the path. Can contain select/omit criterion.

39

Query Access Path

The Query access path specifies a view used by SYNON/2E generated programs to retrieve records from a file using an alternative key order. The Query access path can only be used with reports. Virtual fields can also be used as keys. Keys can be overridden. Though powerful, the Query access path may impact run time performance.

40

Functions

41

What?

What is Function?

What is device design?

Function parameters What does action diagram means?

What are the function options?

How to Link Functions?

42

Introduction to Function

A function defines a list of processes that will operate on the files and fields in database. COOL:2E provides a variety of standard functions with default processing

features; to which we can add our own unique processing.

In addition to the standard function, COOL:2E provides message functions, function fields and built-in-functions.
Function Type Grouping

Interactive

Report

Database

User

43

Function Type Grouping

DSPFIL

Display File

DSPRCD
DSPTRN EDTFIL Interactive EDTRCD EDTTRN PMTRCD SELRCD

Display Record
Display Transaction Edit File Edit Record Edit Transaction Prompt Record Select Record

44

Function Type Grouping

PRTFIL Report

Print File

PRTOBJ

Print Object

CHGOBJ CRTOBJ Database DLTOBJ RTVOBJ

Change Object Create Object Delete Object Retrieve Object

45

Function Type Grouping

EXCINTFUN

Execute Internal Function

EXCEXTFUN Execute External Function

User
EXCUSRPGM Execute User Program EXCUSRSRC Execute User Source

46

Internal Function and External Function

A function can be implemented either as a separate program or as a subroutine within a program as follows.

An external function is implemented as a separate high level language (HLL) program. Each external function is attached to an access path. In general, the standard device functions are external functions; for example, the Edit File function. The only exception is the Print Object (PRTOBJ) function.

An internal function is implemented as source code within that of the calling program; in other words, it is implemented as a subroutine. All the standard database functions are internal functions; for example, the Create Object function (CRTOBJ).

47

Function Component

A standard function consists of four components:

Device Design This specifies the layout of the panel or report used by the function. Action diagram This specifies the processing steps that make up the function. This includes default processing as well as the defined processing. Function options This specifies the default features of a function. Function parameters This specifies fields to be passed to the function and returned from the function at run time.

48

Default Functions

COOL:2E automatically creates 5 default functions for each reference file (REF): two external functions (edit file and select record) and three internal functions (change object, create object, delete object).

For capture file COOL:2E automatically creates three internal functions only.
Edit file (EDTFIL) maintains multiple records on the file and Select record (SELRCD) provides a display of the records on the file and allows the selection of one record for return to the calling program. The three internal functions are called by the external functions for database update.

49

Device Design

COOL:2E automatically creates a default interactive panel design for each interactive device function. We can modify the default designs to meet the requirements of the application.

A device design specify

The selection of fields present on a device panel and the accompanying text for each field. The display of both fields and text may be conditional. The order in which the fields are displayed on the device panel and how they are edited. The display attributes for the fields. The use of each field.

There are two type of device design

Panel Design (similar to SDA) Report Design (similar to RLU)

50

Actions to practice

Displaying the device design outside 80 columns. [F4-F1-F15] Doing Subfile fold. [F9] Checking the panel format details. [Enter Key on first record] Modifying the field usage. Adding a blank line between Subfile records. Placing field labels above, before the field or remove the field label. Change the field label text. Moving fields right/left. [F10-F22] Making fields optional and required.

51

Action Diagram

An action diagram contains the processing steps that make up a function. Each action diagram consists of a list of actions, where each action may be either a call to another function or one of a number of low level built-in functions; for

example, *ADD.

COOL:2E supplies a default action diagram for all functions. The initial display of an action diagram shows it at the summary level. The format and the looping are all defaulted for all the functions. Only the areas which runs the business logic are allowed to change. These areas that we can modify are called as User Point. This are indicated by < - -.

Taking F5 on the Action diagram displays all the possible user points.

52

Construct

Constructs are the basic building blocks of an action diagram. They are always executed from top to bottom. In addition, constructs may be nested; in other words, an action within a construct may be another construct.

There are three different type of constructs:

Sequential Construct A sequential construct is the simplest construct. It is a list of actions or other constructs to be executed in the order in which they appear in the action diagram. It is shown on the action diagram enclosed by a bracket of dots (:).

Conditional Construct A conditional construct specifies a condition and a series of actions to be taken if the condition is true. It is equivalent to an IF THEN ELSE logic statement or a SELECT set. This construct appears on the action diagram between CASE and ENDCASE statements and is enclosed by a bracket of broken vertical bars (|). You can specify several mutually exclusive conditions in a single conditional construct.

53

Construct continues

Iterative Construct An iterative construct includes a list of actions that are to be executed while an initial condition is true. It is equivalent to a DO WHILE logic statement. An iterative construct appears on the action diagram between REPEAT WHILE and ENDWHILE statements. It is indented and enclosed by a bracket of solid vertical bars (|). The controlling condition is specified at the beginning of the bracket.

The following diagram shows the general structure of a COOL:2E action diagram and the three constructs.
. : action 1 : .- CASE : |- controlling condition 1 : | action 2 : |- controlling condition 2 : | .=REPEAT WHILE : | - controlling condition 3 :| action 3 :| action 4 : | -ENDWHILE : ENDCASE : Begin Sequential Construct
Begin Conditional Construct

Begin Iterative Construct

End Iterative Construct End Conditional Construct End Sequential Construct

54

Context

The purpose of a context is to distinguish which version of the field to be used for processing. When we specify logic in action diagram, we need to qualify the field with the appropriate context.

The possible contexts are:

Database DB1; DB2 Device KEY; DTL; 2ND; 3RD; CTL, RCD; CUR; NXT Function PAR, WRK Literal CND; CON System JOB; PGM

It is possible for a filed to be present in more than a context inside a function

similarly it is also possible for a field not to be present in the action diagram. If Order number is a field, then DB1.Order Number means Order Number field from data base and PAR. Order Number means the filed as passed parameter.
55

Database context DB1, DB2

DB1: The DB1 context contains the fields that are in the first or the only format of the access path to which a function is attached. This context is available to all function types that perform update or read functions on a database filed after

reading and before writing to the database file. The functions are CRTOBJ, CHGOBJ, DLTOBJ and RTVOBJ.

DB2: The DB2 context contains the fields that are in the second format of the access path to which a function is attached. Any field in the second access path

are available for processing under DB2 context. The DB2 context is only available for the SPAN access path. The DB2 context is available on the CRTOBJ, CHGOBJ, DLTOBJ and RTVOBJ functions used within EDTTRN or DSPTRN function to access the secondary format.

56

Device Context KEY, DTL, 2ND, 3RD

The idea is to take the key value for the file and retrieve the whole information for the key. The retrieved information is then displayed in the detail panel. We can have 3 detail panel to display the records.

KEY panel Context The key panel is available to functions that operate on single records. For example EDTRCD, DSPRCD. All the fields from the KEY panel will be available under the KEY context. Detail Panel Context If the field is present in any of the display panel then we need to select the context accordingly.

DTL Context is used if the filed is in the first panel. The functions are EDTRCD,
DSPRCD, PMTRCD.

2ND context is used for fields available in the second panel. The functions are

EDTRCD2, DSPRCD2.

3RD context is used for fields available in the third detail panel. The functions are EDTRCD3, DSPRCD3.
57

Device context CTL, RCD

The functions EDTFIL, DSPFIL, SELRCD functions are actually a subfile. So we do have two set of fields. CTL is the subfile control level keyword and RCD is the subfile record level keyword. The subfile fields are actually the part of RCD context fields and the control level fields, position to field are CTL context field.

In general SYNON lists down all the possible context for the user to use. If we are not getting any particular context or field either we are in a wrong user point or otherwise the function we selected is not best for the use. CUR and NXT will be discussed later while in discussing the report.

58

Function context PAR, WRK

PAR: The PAR context contains the fields that we define as parameters for the current function. If we add any parameter to the function, SYNON automatically adds the PAR context. If parameters are not added the PAR context is also not

available.

WRK: The WRK context contains program variable not described not described by any other context. WRK context is available at all the points in the access diagram of all function type. WRK context type is global definition and so can be

changed at any point by any function.

59

Literal Context CND, CON

CND: The CND context is used to control a conditional or iterative construct. The CND context is available for all the functions. However we cant use the CND context in result field i.e. we cant move any value to the CND context field.

The conditions defined for any filed will be available for the CND context of the field.

CON: The CON context contains any constant or literals value that we want to specify.

Status fields allows CND context and not CON context.

Alphanumeric constants must be less than or equal to 20 character length. Numeric constants must be of length less than or equal to 10.

60

SYSTEM Context JOB, PGM

JOB: The JOB context contains system fields that supply execution time information about the job that executes the function. The fields are also system defined and we cant any additional field. These fields can only be used as an

input filed. The fields are like, job date, job start time, user name etc.

PGM: The PGM context contains system fields that control the execution of a function. Ex - *Program Mode.

61

Linking functions Driver function

We can use a driver function which will call another function in a hierarchical structure.

Typical driver functions are: EXXEXTFUN, DSPFIL, PMTRCD. These functions are self explanatory and the navigation logic is well understood from within one function.

62

Linking functions Call to a function

SYNON/2E functions may call other SYNON/2E functions by specifying logic within action diagram.

This is the most common method of linking functions.

63

Parameters

Parameters are one of the method to pass values from one function to another. SYNON/2E explicitly specifies which parameters will be used as input parameter and which will be used as output parameter. SYNON/2E also allows to specify certain to the parameters as used. These parameters have four basic properties:

Name Usage Role Flag Error Status

64

Parameter Roles
The role specifies how the parameter will be used in the function. The valid roles are as below:

MAP Using MAP type parameter passes the value directly to the corresponding field on the function panel. This is an easy way of adding a display only field to the panel. If the function doesnt have any display screen (PRTFIL, PRTOBJ) MAP is ignored. POSITIONAL Only the key fields can be used as a positional parameter. These should be the high order key fields. Using positional behaves like a SETLL with the value and then the READ operation. RESTRICTOR Only the key fields can be used as a restrictor parameter. These should be the high order key fields. Using positional behaves like a CHAIN with the value. VARIABLE - This parameter can have varying length. It is very useful when interfacing with user written subroutines and programs. Domain checking is ignored
65

Default parameters for the standard functions

Function CHGOBJ CRTOBJ

Default Parameter

Usage Input Input Input Input Both

Role

All fields from the update index of the based-on file

All fields from the update index of the based-on file Key fields from the update index of the based-on file Key fields from the associated access path Key fields from the update index of the based-on file

DLTOBJ

Restrictor

RTVOBJ SELRCD

66

Actions to practice

Inserting new constructs. Showing or Hiding hidden constructs. Inserting Comment line; ADD, SUB, MOVE built in function; message function. Moving, Copying or Deleting constructs. Adding multiple condition with ADD/OR condition. Select a particular user point for changes. Searching for other functions or fields. Searing for error messages.

67

User Function

User Functions allow us to specify logic for non standard functions. There are four type of functions:

Execute External Functions (EXCEXTFUN) This allows us to specify the logic in an empty Action diagram. Any other function can call this. This can be used as a driver program for the application; as to modularize the application. Execute Internal Function (EXCINTFUN) This also doesnt have any default logic and comes up with a blank action diagram. Any function can also call this. We can use this function to make a certain logic reusable. Execute User Program (EXCUSRPGM) This is a process to call any RPG program from a SYNON generated function. This allows the user to code in SEU. These are all compiled programs. Execute User Source (EXCUSRSRC) This is a process to use a user source. These are not any compiled program but a piece of source code only. These are also used for reusability.

68

User Function

Internal Function Action Diagram

External Function

EXCINTFUN

EXCEXTFUN

HIGH level Language

EXCUSRSRC

EXCUSRPGM

Subroutine

Program

69

SYNON 2E training model : Tiffany

We need to add Y2SY and SCHMDL in the library list. Next we need to run the following command YSTRY2 SCHMDL. The main three option we use are

Designer It will have all the access. But at one time, only one person can move as Designer. Programmer It can also have all the access. If more than one users are using the application, its preferred to use this option. But a programmer cant do a data modeling. User It can use the application created. It can also view the source or browse through the action diagram

70

Thank You

71