SYNON
SYNON
SYNON
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
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?
3GL High Level Languages. I/O Operation, logical construct, data type.
4GL High Level Language, simplify the coding process, still syntactical.
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
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
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
14
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
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.
16
Example
Entity
Attribute
CUSTOMER MASTER
Customer ID
Customer Name
Primary Key
ITEM MASTER
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.
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.
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
HOSPITAL
Hospital code K
Hospital Hospital
Defined As Known by
WARD
Ward code K
Ward Ward
Defined As Known by
PATIENT
Patient code K
Patient Patient
Defined As Known by
21
Relation Has
HOSPITAL
Hospital code Hospital Name K
Hospital Hospital Code Hospital Name Ward Ward Code Ward Name
WARD
Ward code Ward Name K
PATIENT
Patient code Patient Name Patient Address K
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
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
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
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
PATIENT
Patient code Ward Code Patient Name Patient Address Ward Name K FK V
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?
32
Access path controls how the data is presented to the programs (functions) that manipulate or update
File
Function
33
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
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
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.
SYNON/2E automatically creates this access path when we declare the file in data modeling.
36
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.
37
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
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
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?
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
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
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
PRTFIL Report
Print File
PRTOBJ
Print Object
45
EXCINTFUN
User
EXCUSRPGM Execute User Program EXCUSRSRC Execute User Source
46
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
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.
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.
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.
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
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.
Database DB1; DB2 Device KEY; DTL; 2ND; 3RD; CTL, RCD; CUR; NXT Function PAR, WRK Literal CND; CON System JOB; PGM
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
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
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
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
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
59
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.
60
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
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
SYNON/2E functions may call other SYNON/2E functions by specifying logic within action diagram.
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:
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 Parameter
Role
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
External Function
EXCINTFUN
EXCEXTFUN
EXCUSRSRC
EXCUSRPGM
Subroutine
Program
69
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