Transcript Title of Presentation Name of Author Function Date

Natural Engineer – Refactoring:
From Monolithic Applications to
Service-Oriented Application
Tom Philpott
GSL
[email protected]
Natural Engineer – Next version
Extract is around 60 times quicker
Load is around 40% quicker
New GUI based on an object list rather
than the function driven method of the
current NEE.
Application design through the ages
Structured Design
Object Oriented Programming
Service Oriented Architecture
Refactoring
Structured Design
Coupling
Cohesion
Design Heuristics
What influences Coupling?
Types of connection
Data
Control
Minimally connected
Normally connected
Pathological
What influences Coupling?
Complexity of the interface
Basically, the number of arguments passed.
Information flow
Binding time
Coupling
Common Environment coupling
Decoupling
Convert implicit references to explicit ones.
Localize common environments
Standardize 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 – Control coupling
activating
Control coupling
Control coupling –
activating
Control coupling – Control coupling
coordinating
Control coupling
Control coupling –
coordinating
Common
environment
coupling
Common coupling Global-data
coupling
Common
environment
coupling
Not mentioned
Content coupling
Not mentioned
Content coupling
Cohesion
Yourdon & 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 cohesion
Yourdon &
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
Object
Class
Abstraction
Encapsulation
Inheritance
Polymorphism
Object Oriented Design
Object structure modeling
Model business processes
Derive classes from these business processes
A 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 Refactoring
The Full Scale Refactoring Methodology
Phase I: Preparation
Phase II: DB I/O Separation
Phase III: Presentation Layer Separation
Alternative thinking to Refactoring…
Analyze Data Model
Build Components per conceptual Entity
What is Refactoring?
What is Refactoring ?
Refactoring is a technique for
restructuring or modifying existing
source code without changing it’s
external behavior.
It can
Improve the design of the application
Systematically change program structures
Improve readability of code
Support agile program development
It does not
Change the program functionality
Natural Engineer: Refactoring
Aim of Refactoring
Presentation dialog
with I/O and some
navigation logic
Program with
Presentation Logic
Business Logic
Database I/O
Refactoring
Business Logic
Database I/O
Natural Engineer: Refactoring
Accessing Refactoring
Natural Engineer: Refactoring
The three phases of Refactoring
Natural Engineer - Refactoring
Phase I – Preparation
Processes required in order to prepare the code
for further refactoring
Phase II – DB Split
The ability to create subprograms that perform
the DB access
Phase III – Presentation Split
The 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 Rules
Existing Code
Natural Engineer: Refactoring
Phase 1: Separate Processing Rules
Natural Engineer: Refactoring
Phase 1: Separate Processing Rules
Natural Engineer: Refactoring
Phase I: Conversational DB Loops
Natural Engineer: Refactoring
Phase 1: Conversational DB Loops
Natural Engineer: Refactoring
Phase I: Similar Code Identification
Natural Engineer: Refactoring
Phase I: Similar Code Identification
Natural Engineer: Refactoring
Natural Engineer Refactoring
Phase II: Database I/O
Separation
Natural Engineer: Refactoring
Phase II – DB Split
Creates a subprogram per DDM/Key combination
Creates one subprogram per DDM for single ISN
actions (DELETE, STORE, UPDATE, GET)
Creates one subprogram per application for BT
and ET logic
Then 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: Refactoring
Phase II – DB split – Original Code READWH
Natural Engineer: Refactoring
Phase II: DB Split
Examples of the PDAs created – Record and Key
Natural Engineer: Refactoring
Phase II: DB Split
Subprogram accessing ADABAS – Decide Block
Natural Engineer: Refactoring
Phase II – DB Split
Subroutine handling one particular access
Natural Engineer: Refactoring
Phase II: DB Split
Replacement of ADABAS access in program
Natural Engineer: Refactoring
Natural Engineer Refactoring
Phase III: Presentation Layer
Separation
Natural Engineer Refactoring
Phase III: Presentation Layer Split
Program
…
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
Natural Engineer - Refactoring
Phase III – Presentation Layer
Separation
Natural Engineer - Refactoring
Phase III – Presentation Layer
Separation
Natural Engineer - Refactoring
Phase III – Presentation Layer
Separation
Examination of Cross-Reference Records
Natural Engineer: Refactoring
Phase III: Presentation Split
Items created:
GDAPDA-A – Copy of the GDA
XX021A01 – Map PDA
XX021A02 – Local data PDA
XX021A03 – PDA of XX021L01
XX021A04 – PDA of XX021L02
XX021A05 – PDA of XXMTHVAL
XX021C01/2 – Copy data Map/Local
XX021N01 – Subprogram with BL
XX021P01 – Dialogue program
Natural Engineer Refactoring
Phase III – Presentation Layer
Separation
Natural Engineer Refactoring
 Phase III – Presentation Layer Separation
Natural Engineer Refactoring
Limitations of Refactoring (due to the
nature of an automated process)
Duplication of processing rules in generated
subprograms
 As 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 Model
Why?
All operations within a system stem
from the database data usage
Natural Engineer: Refactoring
The Idea:
Build components based on the conceptual
entities
List Function
Access Function
• Includes formatting
Update Function
• Includes Validation
Source for the new components within
existing application code
Natural Engineer Refactoring
An application tends to have
several functions
Natural Engineer Refactoring
 Where is the code for the new components?
Already in the existing application and ‘normally’
modularlized
 Assuming 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
components
 Rest of component delivered by Object Builder for
Refactoring
Consolidate duplicate code as you go!!!!
Natural Engineer Refactoring
Alternative Approach
Natural Engineer Refactoring
Incrementally refactor each
function…
Natural Engineer Refactoring
Incrementally 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 Scenario
Natural Application
Web
Application
EntireX
U.I
U.I
U.I
B.L
B.L
B.L
D.B
D.B
D.B
Interne
t
Adabas
Implemented with EntireX, IDL Generator, JAVA Class, MQ, Applinx, …
Usage Scenarios
 (Re)Usage of new generated DB objects
Browser
Presentation dialog
with I/O
Navigation logic
Program with
Presentation Logic
Business Logic
Database I/O
Implemented with Natural Business Services, Application Composer, HTML, …
Usage Scenarios
 (Re)Usage of business logic objects and DB I/O
Browser
Presentation dialog
with I/O
Program with
Navigation logic
Presentation Logic
Business Logic
Database I/O
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