Capita Selecta Software Engineering and Technology Migration of Legacy Systems Adapted from chapters

1
Capita SelectaSoftware Engineering and
Technology Migration of Legacy
Systems(Adapted from chapters 6 7 Software
Evolution)

• Hong-Phu Nguyen (h.p.nguyen_at_student.tue.nl)
• April 1, 2009

2
Outline

• Introduction
• Part 1 Architectural Transformations (Ch7)
• From Legacy to Three-Tier and Services
• Service Oriented Architecture
• The Approach to Architectural Transformation
• Part 2 Data-centered Migration (Ch6)
• Migration Reference Model
• The Transformation Approach
• Conversions
• Conclusions
• QA

3
Introduction

• What is Migration of Legacy Information Systems?
• Why?
• Business dimension of evolution
• Technological dimension of evolution
• Adapting an information system to technological
  changes migration
• Dimensions of Migration
• Language
• User Interface
• Database
• Platform and Architecture

4
System Migration State of the Art

• Two migration strategies
• Rewriting the legacy systems from scratch
• Migrating by small incremental steps
• Language dimension
• Dialect conversion
• API migration
• Language migration
• User Interface Dimension
• Migrating user interfaces to modern platforms

5
System Migration State of the Art

• Platform and Architecture Dimensions
• Towards distributed architectures
• Towards object-oriented platforms
• Towards aspect-orientation
• Towards service-oriented architectures
• Database Dimension
• i.e. Migrating relational database to
  object-oriented database technology
• Database reengineering

6
Outline

• Introduction
• Part 1 Architectural Transformations (Ch7)
• From Legacy to Three-Tier and Services
• Service Oriented Architecture
• The Approach to Architectural Transformation
• Part 2 Data-centered Migration (Ch6)
• Migration Reference Model
• The Transformation Approach
• Conversions
• Conclusions
• QA

7
Part 1- Architectural Transformations

• Architectural Transformations From Legacy to
  Three-Tier and Services
• Service Oriented Architecture (SOA)
• Most existing legacy systems are being migrating
  to SOA
• Gartner through 2008, at least 65 percent of
  custom developed services for new SOA projects
  will be implemented via wrapping or reengineering
  of established applications (0.8 probability).

8
Why SOA?

• Legacy systems must be reused rather than
  replaced
• The promise of integrating applications on
  disparate heterogeneous platforms
• CORBA
• Need of an architectural framework which allows
  the assembly of components and services for the
  rapid, and even dynamic, delivery of solutions
• SOA is the best platform for carrying existing IT
  assets into the future?

9
Why SOA? (IBM)
10
Why SOA?

• Benefits of deploying a service-oriented
  architecture
• Leverage existing assets Legacy systems can be
  encapsulated and accessed via Web service
  interfaces
• Infrastructure, a commodity
• Faster time-to-market
• Reduced cost
• Risk mitigation

11
From Legacy to Three-Tier and Services

• Migrating to a service-oriented architecture
• Six basic SOA principles
• Well-defined interfaces
• Loose coupling
• Logical and physical separation of business logic
  from presentation logic
• Highly reusable services
• Coarse-grained granularity
• Multi-party business process orientation

12
From Legacy Systems to Three-Tier Systems and
Services

• Technological Decomposition
• Logical and physical separation of business logic
  from presentation logic
• Reusable Services
• Highly reusable services
• Functional Decomposition
• Coarse-grained granularity
• Multi-party business process orientation

13
Common legacy enterprise IT infrastructure (IBM)
14
Technological Decomposition

• Legacy applications architectural spaghetti
• Business process is tightly coupled with the
  presentation logic.
• Tight coupling between applications.
• Decoupling of the code is required.
• Reengineering towards SOA architectural
  transformation towards a multi-tiered
  architecture.
• Business processes are formed as services

15
Reusable Services

• Legacy systems silos lots of functionality
  is redundant or duplicated.
• SOA services should be called by more than one
  application.
• Prior identification of reusable services across
  multiple functional domains.
• Refactoring redundant functionality to reusable
  services is vital.

16
Functional Decomposition
17
The Approach to Architectural Transformation

• Horseshoe Model
• ArchitectureRecovery
• Architecture
• Transformation
• Architecture-based
• development

www.sei.cmu.edu
18
Methodology
19
Code Annotation

• Source code is annotated by code categories
• The code categories depend on the target
  architecture.
• Technology paradigm
• Intended functional decomposition of target
  system

20
Reverse Engineering

• A graph model is created from the annotated
  source code.
• R1 the relation of source code and source graph
  model.
• Translation AST representation gt graph-based
  representation.
• Why graph representation?
• Language independence
• Intuitive transformation

21
Redesign

• Source graph model is restructured to target
  graph model.
• R2 the relation of source code and target graph
  model.
• Support the code generation
• Code category-driven transformation is specified
  by graph transformation rules.

22
Example of graph model
23
Forward Engineering

• The target code is either generated from
• The target graph model and the original source
  code
• Or
• The use of refactoring at code level
• The whole process can be iterated.
• Good for migrating to a SOA
• Transformation into a three-tier architecture
• Decomposition into functional components

24
Redesign by Graph Transformation

• Metamodelling with Typed Graphs
• Rule-Based Model Transformations
• Well-Defineness and Correctness of
  Transformations
• Partial Correctness
• Total Correctness
• Uniqueness

25
Implementation and Example

• To do

26
Outline

• Introduction
• Part 1 Architectural Transformations (Ch7)
• From Legacy to Three-Tier and Services
• Service Oriented Architecture
• The Approach to Architectural Transformation
• Part 2 Data-centered Migration (Ch6)
• Migration Reference Model
• The Transformation Approach
• Conversions
• Conclusions
• QA

27
Part 2 Data-centered Migration

• A practical approach to data-intensive
  application reengineering based on
• The data
• The programs
• Conversion of the database to a new data
  management paradigm
• Adaptation of the application programs to the
  migrated database schema and to the target data
  management system

28
Migration Reference Model
29
Migration Reference Model

• Schema conversion
• (1) Recovering the conceptual schema expressing
  the semantics of the source data structure
  (database reverse engineering)
• (2) Deriving the target physical schema from the
  conceptual schema
• Data conversion
• Program conversion

30
Migration Strategies

• The database dimension (D)
• Physical conversion (D1) without attempting any
  semantic interpretation.
• Conceptual conversion (D2) more expensive
• The program dimension (P)
• Wrappers (P1)
• Statement rewriting (P2)
• Logic rewriting (P3)

31
The Transformation Approach

• Schema transformation
• Compound schema transformation
• Transformation history and schema mapping
• Program transformation

32
Schema Conversion

• Two transformation strategies
• Physical schema conversion (D1) simulates the
  explicit constructs of the legacy database into
  the target DMS
• Conceptual schema conversion (D2) the complete
  semantics of the legacy database is retrieved and
  represented to develop the new database

33
Physical Conversion Strategy (D1)

• The DDL parsing process analyses the DDL code to
  retrieve the physical schema of the source
  database (SPS)
• Schema conversion SPS gt TPS
• Target schema mapping

34
Conceptual Conversion Strategy (D2)
35
Data Conversion

• Data migration architecture (Extract-Transform-Loa
  d ELT) converter and schema transformation
• Extraction of the data from the legacy database
• Transform these data to match the target format
• Write these data in the target database

36
Program Conversion

• Three strategies
• Wrapper technology (P1) maps the access
  primitives onto the new database via wrapper
• Statement rewriting (P2) replaces each statement
  with its equivalent in the new DMS
• Logic rewriting (P3) rewrites the access logic to
  comply with the DML of the new DMS

37
Wrapper Strategy (P1)

• A wrapper allows the data managed by a new DMS to
  be accessed by the legacy programs.

38
Statement Rewriting (P2)

• Replacing legacy DMS-DML statements with native
  DML statements of the new DMS.
• Physical schema conversion (D1)
• SPS-to-TPS mapping
• The conversion process can be easily automated
• Conceptual schema conversion (D2)
• Flattens complex source structures in the target
  relational schema
• Substitution process is more complex than D1
• The conversion process can be fully automated

39
Logic Rewriting (P3)

• The program is rewritten
• Access the new data structures
• In-depth understanding of the program logic is
  required
• Methodology
• (1) identifying the file access statements
• (2) identifying and understanding the statements
  and the data objects
• (3) rewriting these statements as a whole and
  redefining these data objects

40
Anything else in chapter 6?

• Tool Support
• Industrial Application
• Strategies Comparison
• Database Conversion Strategies D1 vs. D2
• Program Conversion Strategies P1 vs. P2 vs. P3
• System Migration Strategies Six Combinations

41
Conclusions

• In theory, theory and practice are the same. In
  practice, they are not. Laurence
• Apply a tool to a case of migrating to SOA

42
Thanks for your attention!