Natural Engineer Refactoring: From Monolithic Applications to ServiceOriented Application Tom Philpo

1
Natural Engineer RefactoringFrom Monolithic
Applications to Service-Oriented ApplicationTom
PhilpottGSLModernization_at_gensystems.com
2
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.

3
Application design through the ages

• Structured Design
• Object Oriented Programming
• Service Oriented Architecture
• Refactoring

4
Structured Design

• Coupling
• Cohesion
• Design Heuristics

5
What influences Coupling?

• Types of connection
• Data
• Control
• Minimally connected
• Normally connected
• Pathological

6
What influences Coupling?

• Complexity of the interface
• Basically, the number of arguments passed.
• Information flow
• Binding time

7
Coupling

• Common Environment coupling
• Decoupling
• Convert implicit references to explicit ones.
• Localize common environments
• Standardize connection

8
Various takes on coupling
9
Cohesion
10
Various takes on cohesion
11
Design Heuristics

• A module shouldnt be any bigger than 100
  statements.
• The span of control shouldnt 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.

12
Object Oriented Programming

• Object
• Class
• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

13
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.

14
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.

15
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.

16
SOA
17
Refactoring

• Refactoring

18
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

19
What is Refactoring?

• What is Refactoring ?
• 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

• Refactoring is a technique for restructuring or
  modifying existing source code without changing
  its external behavior.

20
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
21
Natural Engineer Refactoring

• Accessing Refactoring

22
Natural Engineer Refactoring

• The three phases of Refactoring

23
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

24
Natural Engineer Refactoring

• Natural Engineer Refactoring
• Phase I Preparation

25
Natural Engineer Refactoring

• Phase 1 Preparation

26
Natural Engineer Refactoring

• Phase 1 Preparation

27
Natural Engineer Refactoring

• Phase 1 Preparation

28
Natural Engineer Refactoring

• Phase 1 Separate Processing Rules
• Existing Code

29
Natural Engineer Refactoring

• Phase 1 Separate Processing Rules

30
Natural Engineer Refactoring

• Phase 1 Separate Processing Rules

31
Natural Engineer Refactoring

• Phase I Conversational DB Loops

32
Natural Engineer Refactoring

• Phase 1 Conversational DB Loops

33
Natural Engineer Refactoring

• Phase I Similar Code Identification

34
Natural Engineer Refactoring

• Phase I Similar Code Identification

35
Natural Engineer Refactoring

• Natural Engineer Refactoring
• Phase II Database I/O Separation

36
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.

37
Natural Engineer Refactoring

• Phase 2 Data I/O Separation

38
Natural Engineer Refactoring

• Phase II DB split Original Code - READWH

39
Natural Engineer Refactoring

• Phase II DB Split
• Examples of the PDAs created Record and Key

40
Natural Engineer Refactoring

• Phase II DB Split
• Subprogram accessing ADABAS Decide Block

41
Natural Engineer Refactoring

• Phase II DB Split
• Subroutine handling one particular access

42
Natural Engineer Refactoring

• Phase II DB Split
• Replacement of ADABAS access in program

43
Natural Engineer Refactoring

• Natural Engineer Refactoring
• Phase III Presentation Layer Separation

44
Natural Engineer Refactoring

• Phase III Presentation Layer Split

Dialog (Program) SET KEY INPUT USING MAP MOVE 1
TO NAV-BLOCK CALLNAT NEWSUBP DATA
Program

• processing.
• SET KEY
• INPUT USING MAP processing.

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 DEFI
NE SUBROUTINE BLOCK2 Processing END-SUBROUTINE
45
Natural Engineer - Refactoring

• Phase III Presentation Layer Separation

46
Natural Engineer - Refactoring

• Phase III Presentation Layer Separation

47
Natural Engineer - Refactoring

• Phase III Presentation Layer Separation
• Examination of Cross-Reference Records

48
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

49
Natural Engineer Refactoring

• Phase III Presentation Layer Separation

50
Natural Engineer Refactoring

• Phase III Presentation Layer Separation

51
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 11 relationship. Are the
  components truly reusable? Maybe not!

52
Natural Engineer Refactoring

• Natural Engineer Refactoring
• Alternative Approach
• Ask the Question
• WHAT VALUE DOES THIS GIVE ME?

53
Natural Engineer Refactoring

• Start from the Data Model
• Why?
• All operations within a system stem from the
  database data usage

54
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

55
Natural Engineer Refactoring

• An application tends to have several functions

56
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!!!!

57
Natural Engineer Refactoring

• Alternative Approach

58
Natural Engineer Refactoring

• Incrementally refactor each function

59
Natural Engineer Refactoring

• Incrementally refactor each function

60
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.

61
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

62
Usage Scenario
Natural Application
Web Application
EntireX
Internet
Adabas
Implemented with EntireX, IDL Generator, JAVA
Class, MQ, Applinx,
63
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,
64
Usage Scenarios

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

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,
65
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