Natural Engineer

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
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
9
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.
10
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
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