Information Engineering Facility

Information Engineering Facility, called IEF, Composer

or COOL:Gen, is a Software Development Life Cycle Tool
based on the Concept of Information Engineering
Information Engineering
A methodology for developing and maintaining business oriented
information systems

There are seven stages in Information Engineering

Seven Stages
Information Strategy Planning(ISP)
 Establishing a broad view of the information requirements of the business

Business Area Analysis(BAA)

 Detailed analysis on a particular segment of business, called
BUSINESS AREA

Business System Design (BSD)

 Description on application system of one segment of Business Area in
detail
 Does not take in account target computing environments
Seven staged Contd..
Technical Design
 Tailoring of BSD to specific target computing environment.
 Takes into account the characteristics of OS, hardware, DBMS etc

Construction
 Creation of executable components of a system

Transition
 Installation of new system in production environment in an orderly manner

Production
 Execution of application system satisfying the portion of business
 requirements identified in ISP
Business System
Implementation
BSI repackages BSD, TD and
Construction into a single phase

BSI allows incremental delivery of the

system, enabling particular strengths or
weaknesses to be identified at the
earliest stage.
Business System
Implementation
INPUTS TO BSI :
 Project Definition, Scope, Objective and Goals
 Data and Process Models from BAA

DELIVERABLES OF BSI :
 Accepted Business System, ready for Implementation
 Updates to Business Area Models
Objectives of ISP
 To collect Information Requirements of the
Enterprise
 To construct an Information Architecture that will
satisfy the requirements
 To construct a Business System Architecture that
supports the implementation of the Information
Architecture
 To identify the Technical Architecture to support
the Business System Architecture
 To present the project findings in a way top
management can readily understand, evaluate
and act upon
Business Area Analysis
Data Analysis- Information required by the business
Activity Analysis-Analysis of Business functions to determine the
Business processes they comprise of
Current Systems Analysis-Analysis of the existing system
Interaction Analysis-Interaction between Data and Activities
BAA Model Confirmation
 Compare the output of Interaction Analysis with the existing system
Data Analysis

In Data Analysis, we look at Business

Objects which are
Things of interest to the business about which data
needs to be kept.
Identify their characteristics and descriptors.
Relationships to other things of interest to the business.
Activity Analysis
Understand the process of the User
Verify the understanding with user
Provide basis for the system design
Business Activities
Function
 A group of business activities that together completely support one aspect
of the enterprise. Functions are broken down into processes.

Process
 A defined business activity whose executions may be defined in terms of
the input and output of specific entities. They are broken further into more
processes.

Procedure
 The method of carrying out one or more of the lowest level processes
What is function?
High level Business activity
Independent of organizational structure
Not executable
Name refers to a subject area of group of
activities
What is process?
A process is executable.
It uses required input (Customer Details in
e.g.), changes data (Customer status in e.g.),
does work and produces output (Customer
accepted or rejected) that are meaningful to
the business.
What is procedure?
A way of carrying out specific action
Practical view of one possible way to
implement the process.
Elementary Process
An Elementary Process is the smallest unit of Business Activity, of

meaning to a user, which, when complete, leaves the business in a

consistent state.

The result must support a business need.

Elementary Processes mark the level at which Activity Decomposition

ceases.

The main output of Activity Analysis is a complete list of Elementary

Processes.
Activity Hierarchy Diagram
The Activity Hierarchy Diagram is created at this stage with all
Functions and Processes including elementary processes. This is how
it looks in IEF.
Interaction Analysis
Examines the usage of objects identified in data
model by the objects identified in activity
model

Data Model Objects (Entities,

attributes..etc) are used by Activity
model objects like function,process
&procedure.
Interaction Analysis
Interaction Analysis will help confirm the two
sides of a model, data and activities against
each other. The techniques will formalize on
the internal structure of the elementary
processes and their relationship to the data
model in terms of data requirements and
expected effects on the data.
Business System Design
A collection of closely related processes,
entity types, relationships and attributes
Practical implementation of logical analysis
Data Model is foundation for data sharing
systems Activity Models are foundation for
system procedures
Upon completion of the analysis the business
area is scoped into smaller design areas. The
scope will try and group like with like to form
integrated systems.
What is Business System?
A business system describes HOW activities will be
performed, as well as WHAT will be performed
(identified during BAA project).

It is concerned with the ways in which the user wishes

to interact with the business.

A Business System will consist of Procedures.

Business System Design

Business System Defaults

Dialog Design

Screen Design

Window Design

Prototyping

Action Diagramming
What is Cool:gen?
Cool:gen is a component based
development system(CBD).
 CBD is a new delivery solution that is based on
the idea of assembling pre-tested components
into applications.
Construction

Construction is the stage of the COOL:Gen

development process where the diagrams created
during Planning, Analysis, and Design are used to
build an executable application system. The various
application types that you can construct include:
 Diagram
 Entities & attributes
 Consistency check with no error will generate DDL
 Construct will generate IP
Prerequisites

The Construction client uses certain diagrams in

construction processing:
 Data Model Diagram (DMD)
 Technical Design (TD)
 Dialog Flow Diagram (DLG)
 Action Diagram(s) (AD)
 Screens built using the Screen Design (SD) Tool (for a
character-based application)
Prerequisites
Contd..
Other prerequisites must also be met before you can
complete the Construction process:
 Model must pass a Consistency Check with no errors and
the required diagrams must be complete. (This process is
done within the Toolset.)
 Upload the model to the encyclopedia.
 You must be the encyclopedia administrator or model
owner, or have Update (for packaging) or Generate (for
generation) authority for a model.
Overview of Construction
The goal of Construction is to generate an executable application
defined during earlier stages of the application development process.
On the mainframe (or Host), COOL:Gen supports construction of
COBOL applications for execution under MVS accessing DB2 databases.
Using Host Construction, you can construct online, batch, and server
applications. Online applications may execute under IMS, CICS, and
TSO; servers may execute under IMS and CICS.
COOL:Gen supports Construction with these toolsets:
· Database Construction
· Referential Integrity Trigger Construction
· Application System Construction (source and executable code)
Construction Primary Function
 Generate Databases
 Generate Referential Integrity modules
 Package Load Modules
 Specify Target Environment and Construction
Libraries
 Generate the Application System
 Test the Application System
Database Construction
Toolset

The Database Construction Toolset

builds the Database Definition for the
database defined during Design. For
DB2, it generates JCL and DDL
statements that allocate and construct
the DB2 database objects. This toolset
also generates the JCL to execute
several DB2 utilities.
Referential Integrity
Trigger Construction
Toolset
The Referential Integrity Trigger Construction
Toolset supports generation of the source
code and object code modules that maintain
the validity of data when an entity is deleted
or a relationship is disassociated. The need
for Referential Integrity arises from the
relationship memberships established
between entities in the Data Model (Entity
Relationship Diagram).
Application System
Construction Toolset
The Application System Construction
Toolset supports system generation and
installation of online, batch, and server
applications. During system generation
and installation, COOL:Gen constructs
COBOL programs and, for local
installations, executable load modules.
Application System
Construction Toolset Contd..
The toolsets use information from the
diagrams created during the preceding stages
of Information Engineering to generate the
application system. This information is stored
in the Host Encyclopedia, which is the primary
source of information for system generation
and database generation. The following
diagrams must be completed before
Construction begins.
Application System
Construction Toolset Contd..
Database generation requires:
 Data Store List and Data Structure List
System generation requires:
 Entity Relationship Diagram
 Dialog Flow Diagram
 Screen Design Diagram(s) (for online applications)
 Procedure Action Diagram(s)
 Technical Design diagram
Referential Integrity generation requires:
 Data Structure
 Data Model
You produce these diagrams using COOL:Gen at the
workstation level.
Package Load Modules

Load module packaging defines how

procedure steps are grouped for
installation
Load module packaging does not create
the load modules. This is done by code
generation
Specify Target Environment
and Construction Libraries
Operating System
Generated Source Language
Database Management System
Teleprocessing (TP) Monitor(CICS &
IMS)
Screen Format Type
Specify Target Environment
and Construction Libraries
COOL:Gen allows flexibility in how you
specify the target environment and the
construction libraries. You may use the
same specifications for all business
systems in a model, or you may use
different specifications for separate
business systems.
Specify Target environment
and Construction Libraries
The target environment and the construction libraries
must be specified before the system generation
functions can be executed.
The libraries must be allocated outside of
COOL:Gen. The allocation of libraries is not a
function of COOL:Gen.
The specifications are made at the business system
level and are stored in the Host Encyclopedia. This
means that you must specify the libraries and the
environment for each business system.
Specify Target Environment
and Construction Libraries
Construction Libraries
The construction libraries, which are partitioned data
sets (PDS), store the objects created during system
generation. The generated objects are PDS
members.(load libraries & general libraries)
If the target environment for an COOL:Gen
application is IMS or CICS or both, you need to
configure the environment(s) before that application
can be generated.
Generate the Application
System
The system generation tools support the following
functions:
 Run Consistency Check
 List Procedure Action Diagram
 Generate Load Module
 Generate VS COBOL II Source
 Generate Dialog Manager, Batch Manager, or Server
Manager
 Generate Screen Definitions
 Generate JCL to Execute Batch Applications
Generate the Application
System Contd..
 Generate Installation Control Information
 Compile Generated Components (local)
 Link-Edit Compiled Source (Preliminary) (local)
 Generate Remote Installation files
 Generate a Load Module Component
 Rename Source Members
 Generate an External Action Block Stub
 Resolve an External Action Block
 Install a Load Module (local or remote)
 Test the Application System
Load Module Packaging
You must specify which components comprise the load
modules for a business system before generating the
executable components of your application system.
The specification of the components is called load
module packaging.
The packaging itself does not create the load modules;
it simply identifies what makes up a load module. A
load module is created when you generate and install it.
These methods of packaging are available on the Host:
· Online
· Batch
Online Packaging
To package for online processing,
COOL:Gen displays a list of the online
procedure step names for the selected
business system. You supply the
names for these components:
 · Load Modules
 · Clear Screen Transaction Codes
 · Dialog Flow Transaction Codes
Batch Packaging

To package for batch processing,

COOL:Gen displays a list of the batch
procedure step names for the selected
business system. You supply the
names for these components:
 · Load Modules
 · Job names
 · Job Steps
System Generation and
Installation
The system generation and installation
functions create the source code and the
executable components, respectively, of an
application system. The two phases in
application system construction are:
 · Source code generation
 · Installation
System Generation and
Installation
During source code generation, COOL:Gen
generates COBOL source code, MFS source
for online IMS systems, and JCL for batch
jobs. COBOL source must be generated for
all required components of a load module
before the load module can be installed.
The generated source modules are stored in
the Internal Source Code library specified for
the business system.
Installation

You can select local or remote

installation. Choose local to install the
application for the MVS operating
system under which the generators are
running. Choose remote to install the
application on another MVS platform.
Testing Applications
COOL:Gen provides an Application Test Facility that
allows you to test new systems or changes to systems
in a TSO testing environment that simulates your
target production environment. Online (IMS, CICS,
TSO) and batch applications may be tested with the
Test Facility. To test an application system, you
generate and install the load modules into the testing
environment and execute the test. During the test,
you see how your system behaves at runtime.
COOL:Gen also provides a Debug Trace Facility that
can be used to debug
MVS deployment
Implementation Toolset
The Implementation Toolset is a collection of tools that
allow you to construct, test and maintain a COOL:Gen-
generated application. The Implementation Toolset is
divided into five distinct parts.
Application Execution Facility
 The Application Execution Facility (IEFAE) is an
interface between the operating system
environment and the user.
Installation Tool
 The Installation Tool performs code and
database installation on the target platform.
MVS deployment
Implementation Toolset
Application Test Facility
 The Application Test Facility allows you to test a COOL:Gen-
generated application by interactively stepping through the
action diagrams.
Runtime Routines
 The runtime routines are separate "reusable code" modules
that perform low-level functions such as:
 accessing the runtime profile database (RPROF table)
 parsing unformatted input
 formatting screen output
Background Utility
 The background utility is a TSO function that allows you to run
JCL, process multiple command procedures, and continue to
access the terminal at the same time.
Application Maintenance

All maintenance of a COOL:Gen-

generated application must be
performed on the model where the
application is generated. Until changes
are necessary, store the model in the
Host Encyclopedia or the CSE with
appropriate backup copies stored
separately for recovery, if necessary.
WARNING:
Do not modify the generated source
code. Always make any necessary
changes to the related action diagrams,
views, and screens, and then
regenerate the source. If you modify
the generated source code, the results
after installation will be unpredictable.
BASIC OVERVIEW OF THE
IEF LIFE CYCLE
 Check out a subset to be downloaded if
needed.
 .Download the subset to the PC from the
encyclopedia.
 .FTP (Option 6) to the PC.
 .In COOL:Gen on the PC, download the subset
to the PC
 .Make necessary programming changes.
 Upload these changes (without check-in) to
the encyclopedia from the PC.
BASIC OVERVIEW OF THE
IEF LIFE CYCLE
 .FTP (Option 6) to the encyclopedia.
 .In the encyclopedia, update subset.
 .Generate changes into the test environment.
 .Test changes in Test region.
 .Once changes have been tested and are
correct, perform a trial migrate to
acceptance model
 .Generate changes from the acceptance
model
BASIC OVERVIEW OF THE
IEF LIFE CYCLE
 .Package elements and move from Test1 to
Test2
 .Test changes in TRIMS (if needed have
users test also)
 .Once users approve of the changes, package
elements to move to production
 .Once changes have moved to production and
it has been determined that everything is
okay the subset migrated to the Production
Model.
Understand the Mainframe &
PC environment for models
Mainframe Environment
 All models are stored in the Mainframe
environment of COOL:Gen. All work is begun in
the SPS DEVELOPMENT MODEL. Once the
changes have been made and are accurate, they
are migrated to the SPS ACCEPTANCE MODEL.
These changes are tested again to verify
accuracy and then they will be migrated to the
Production Model.
PC environment
 All changes are made to the model in the PC
Application of COOL:Gen. In order to complete
these changes, the required object need to be
downloaded to the PC. Once the changes are
complete or are ready for testing, they must be
uploaded to the Mainframe.

 Once a Model has been downloaded, the

Mainframe believes you have it checked out
until you have uploaded it back to the
Mainframe.
PC environment Contd..
 There are two way to upload a model, one is with check-
in and one is with-out check-in. If you upload with
check-in, the Mainframe Encyclopedia now believes that
you no longer have the subset checked out. No new
changes can be made on the PC unless the subset is
downloaded again. If you upload with-out check-in, the
Mainframe Encyclopedia believes that you still have the
subset checked-out. You are still able to make changes
to the PC model and continue to upload for testing.
 It is best to not upload with check-in until you are
certain that all changes have been made and are correct.