Upload
blair-bell
View
32
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
Natural Engineer – Refactoring:From Monolithic Applications to
Service-Oriented Application
Tom PhilpottGSL
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