natural engineer – next version

Natural Engineer – Refactoring:From Monolithic Applications to

Service-Oriented Application

Tom PhilpottGSL

Modernization@gensystems.com

Natural Engineer – Next version

Extract is around 60 times quickerLoad is around 40% quickerNew GUI based on an object list rather

than the function driven method of the current NEE.

Application design through the ages

Structured DesignObject Oriented ProgrammingService Oriented ArchitectureRefactoring

Structured Design

CouplingCohesionDesign Heuristics

What influences Coupling?

Types of connectionDataControlMinimally connectedNormally connectedPathological

What influences Coupling?

Complexity of the interfaceBasically, the number of arguments passed.

Information flowBinding time

Coupling

Common Environment couplingDecoupling

Convert implicit references to explicit ones. Localize common environmentsStandardize connection

Various takes on coupling

Yourdon & Constantine

Martin & McClure McConnell Budgen

Data coupling or input-output coupling

Data coupling Simple-data coupling

Data coupling

Not mentioned Stamp coupling Data-structure coupling

Stamp coupling

Control coupling – activating

Control coupling Control coupling Control coupling – activating

Control coupling – coordinating

Control coupling Control coupling Control coupling – coordinating

Common environment coupling

Common coupling Global-data coupling

Common environment coupling

Not mentioned Content coupling Content coupling Not mentioned

CohesionYourdon & Constantine Example

Functional Every element of the code is necessary for process

Sequential Code in which the output of one process is input for the next process.

Communicational Code in which each line deals with the transformation of the input or output data.

Procedural Code that is placed in a loop or after some sort of decision.

Temporal An initialization routine.

Logical A generalized input or error routine.

Coincidental Code that just is thrown together just because it is there.

Various takes on cohesionYourdon & Constantine

Martin & McClure McConnell Budgen

Functional Functional Functional Functional

Sequential Sequential Sequential Sequential

Communicational Communicational Communicational Communicational

Procedural Procedural Temporal Procedural

Temporal Temporal Procedural Temporal

Logical Logical Logical Logical

Coincidental Coincidental Coincidental Coincidental

Design Heuristics

A module shouldn’t be any bigger than 100 statements.

The span of control shouldn’t exceed 7 plus/minus 2.A high span of control can meant the module

was broken down too much.

When you identify reuse possibilities the process is called fan-in.

Object Oriented Programming

ObjectClassAbstractionEncapsulationInheritancePolymorphism

Object Oriented Design

Object structure modelingModel business processesDerive classes from these business processesA business process is a set of activities for

transforming some kind of input into a product that a customer is willing to pay for.

Coad/Yourdon guidelines

Focus on clarity of design If you cannot understand what someone is doing, you will not

use the object.Keep message protocols simple

Coupling is discussed here as well. If a message requires more than three parameters, it is badly designed.

Keep operations simple Code should be less than one “page”.

Minimize design volatility A bad design requiring frequent changes can be spotted through

a configuration management system.Minimize overall system size – big is bad.

A medium size system should not require more than a few dozen class hierarchies.

Service Oriented Architecture

Utilizes loosely coupled software services to support business process requirements

Resources are available and accessible without any need to know the underlying platform

Not necessarily tied to a technology, could be RPC, DCOM, .Net, ORB or WSDL.

Architecture for creation of composite applications from loosely coupled services.

SOA

Refactoring

Refactoring

Refactoring Topics

What is Refactoring?Small Scale RefactoringThe Full Scale Refactoring Methodology

Phase I: PreparationPhase II: DB I/O SeparationPhase III: Presentation Layer Separation

Alternative thinking to Refactoring…Analyze Data ModelBuild Components per conceptual Entity

What is Refactoring?What is Refactoring ?

It canImprove the design of the applicationSystematically change program structuresImprove readability of codeSupport agile program development

It does notChange the program functionality

Refactoring is a technique for restructuring or modifying existing source code without changing it’s external behavior.

Natural Engineer: Refactoring

Presentation dialogwith I/O and somenavigation logic

Business Logic

Database I/O

Aim of Refactoring

Program with

Presentation LogicBusiness LogicDatabase I/O

Refactoring

Natural Engineer: Refactoring

Accessing Refactoring

Natural Engineer: Refactoring

The three phases of Refactoring

Natural Engineer - Refactoring

Phase I – PreparationProcesses required in order to prepare the

code for further refactoring

Phase II – DB SplitThe ability to create subprograms that perform

the DB access

Phase III – Presentation SplitThe ability to create subprograms that contain

the business logic

Natural Engineer: Refactoring

Natural Engineer Refactoring

Phase I: Preparation

Natural Engineer: Refactoring

Phase 1: Preparation

Natural Engineer: Refactoring

Phase 1: Preparation

Natural Engineer: Refactoring

Phase 1: Preparation

Natural Engineer: Refactoring

Phase 1: Separate Processing RulesExisting Code

Natural Engineer: Refactoring

Phase 1: Separate Processing Rules

Natural Engineer: Refactoring

Phase 1: Separate Processing Rules

Natural Engineer: RefactoringPhase I: Conversational DB Loops

Natural Engineer: RefactoringPhase 1: Conversational DB Loops

Natural Engineer: RefactoringPhase I: Similar Code Identification

Natural Engineer: RefactoringPhase I: Similar Code Identification

Natural Engineer: Refactoring

Natural Engineer Refactoring

Phase II: Database I/O Separation

Natural Engineer: RefactoringPhase II – DB Split

Creates a subprogram per DDM/Key combinationCreates one subprogram per DDM for single ISN

actions (DELETE, STORE, UPDATE, GET)Creates one subprogram per application for BT

and ET logicThen replaces ADABAS logic in original program

to CALLNAT to newly created subprograms.Remember: USR4011N from SYSEXT to

SYSTEM. This is the module that creates the hashing number for optimistic locking.

Natural Engineer: Refactoring

Phase 2: Data I/O Separation

Natural Engineer: RefactoringPhase II – DB split – Original Code -

READWH

Natural Engineer: RefactoringPhase II: DB Split

Examples of the PDAs created – Record and Key

Natural Engineer: RefactoringPhase II: DB Split

Subprogram accessing ADABAS – Decide Block

Natural Engineer: RefactoringPhase II – DB Split

Subroutine handling one particular access

Natural Engineer: RefactoringPhase II: DB Split

Replacement of ADABAS access in program

Natural Engineer: Refactoring

Natural Engineer Refactoring

Phase III: Presentation Layer Separation

Natural Engineer Refactoring

… processing….

SET KEY INPUT USING MAP

… processing….

Dialog (Program)SET KEY

INPUT USING MAP

MOVE 1 TO #NAV-BLOCK

CALLNAT ‘NEWSUBP’ #DATA

Business logic (Subprogram)DECIDE ON FIRST VALUE OF #NAV-BLOCK

VALUE 1 PERFORM ##BLOCK1

VALUE 2 PERFORM ##BLOCK2

..

END-DECIDE

…

DEFINE SUBROUTINE ##BLOCK1

Processing

END-SUBROUTINE

DEFINE SUBROUTINE ##BLOCK2

Processing

END-SUBROUTINE

Program

Phase III: Presentation Layer Split

Natural Engineer - RefactoringPhase III – Presentation Layer

Separation

Natural Engineer - RefactoringPhase III – Presentation Layer

Separation

Natural Engineer - RefactoringPhase III – Presentation Layer

SeparationExamination of Cross-Reference Records

Natural Engineer: RefactoringPhase III: Presentation Split

Items created:

GDAPDA-A – Copy of the GDAXX021A01 – Map PDAXX021A02 – Local data PDAXX021A03 – PDA of XX021L01XX021A04 – PDA of XX021L02XX021A05 – PDA of XXMTHVALXX021C01/2 – Copy data Map/LocalXX021N01 – Subprogram with BLXX021P01 – Dialogue program

Natural Engineer RefactoringPhase III – Presentation Layer

Separation

Natural Engineer RefactoringPhase III – Presentation Layer Separation

Natural Engineer RefactoringLimitations of Refactoring (due to the

nature of an automated process)Duplication of processing rules in generated

subprogramsAs the subprogram is generated per map, if two maps

have the same processing rule, then it is duplicated in two subprograms

This can be addressed by similar code identification

A single program, due to the internal structure, may generate many blocks. This may make it difficult to expose as a service.

The Blocks are per program and when reworking the UI, it may not be a 1:1 relationship. Are the components truly reusable? Maybe not!

Natural Engineer: Refactoring

Natural Engineer Refactoring

Alternative Approach…

Ask the Question:

WHAT VALUE DOES THIS GIVE ME?

Natural Engineer Refactoring

Start from the Data ModelWhy?

All operations within a system stem from the database data usage

Natural Engineer: Refactoring

The Idea:Build components based on the conceptual entities

List FunctionAccess Function

• Includes formattingUpdate Function

• Includes Validation

Source for the new components within existing application code

Natural Engineer RefactoringAn application tends to have

several functions

Natural Engineer RefactoringWhere is the code for the new components?

Already in the existing application and ‘normally’ modularlizedAssuming Phase I completed, then the access to the

database should be in discrete code.Locate code using existing Natural Engineer functionality.

Current estimation based on real projects:40% of existing code will be reused (not navigation logic)This 40% of code will build over 80% of the new componentsRest of component delivered by Object Builder for Refactoring

Consolidate duplicate code as you go!!!!

Natural Engineer RefactoringAlternative Approach

Natural Engineer RefactoringIncrementally refactor each

function…

Natural Engineer RefactoringIncrementally refactor each

function…

Natural Engineer Refactoring

If the Data Model is also changing, utilize DB Split on the new access modules to create a ‘data shield’ between the application and the physical data.

Natural Engineer Refactoring

The incremental approach means:• LESS RISK!!!

Resulting in real value for customers:• Single route to database• Truly reusable components• New UI not dependent on existing UI (as the

components based on conceptual entites).• Improved reliability and maintenance of

application.• Improved time-to-market for ever increasing

business requirements

Usage ScenarioNatural Application

U.I

B.L

D.B

U.I

B.L

D.B

U.I

B.L

D.B

InternetInternet

Adabas

WebApplication

En

tire

X

Implemented with EntireX, IDL Generator, JAVA Class, MQ, Applinx, …

Usage Scenarios

Presentation dialogwith I/O

Navigation logic

Business Logic

Database I/O

(Re)Usage of new generated DB objects

Program with

Presentation Logic

Browser

Implemented with Natural Business Services, Application Composer, HTML, …

Usage Scenarios

Presentation dialogwith I/O

Navigation logic

Business Logic

Database I/O

(Re)Usage of business logic objects and DB I/O

Program with

Presentation Logic

Browser

Implemented with Natural Business Services, Application Composer, HTML, …

Natural Engineer Refactoring The approach

Natural Engineer provides a Toolkit to assist with Refactoring Projects - One solution will not cover all projects

High level of automation Result

Flexible – UI independence Easy Maintenance Reusability of business logic for other and new applications Represents a Service Oriented Architecture

Business Cost effective solution Project can be outsourced Opens application for future changes Stay competitive with reusable, stable business logic