Refactoring Information Systems Michael Löwe, FHDW Hannover Oldenburg, January 9, 2007.

Refactoring Information Systems

Michael Löwe, FHDW Hannover

Oldenburg, January 9, 2007

January 9, 2007 Oldenburg 2

ContentsMotivating Example

State-of-the-Art in (German) Industry

Abstract Graph Model

Refactorisations and Migrations

From Pullback-Complements to Abstract Foldings

Formal Treatment of the Examples

Sequential Composition

Further Research and Development

Refactoring Information Systems

RefactoringInformation Systems


Refactoring Example

Address

Person

BankAcc.

*

*

Contract

Claim

partner

claimant

inAcc.

outAcc.

inAcc.

outAcc.Contract

Claim

partner

claimant

Role

• Splitting Classes (for example: Person >>> Person / Role)

• Redirecting Associations (for example: partner : Person >>> Role)


Refactoring Example (cont.)

inAcc.

outAcc.

partner

claimant

Role

Contract

Person

BankAcc.

*

Address*

Claim

inAcc.

outAcc.

partner

claimant

• Introducing Inheritance (for example: Role >>> Partner/Claimant)

• Redirecting Associations (for example: inAcc and outAcc)

Partner

Claimant

{abs}



Contract

Person

BankAcc.

*

Address*

Claim

partner

claimant

Partner

Claimant

Role{abs}

inAcc.

outAcc.

account

• Shifting Associations (for example: up the inheritance hierarchy)

• Abstracting Associations (for ex.: inAcc and outAcc into account)



claimantClaimClaimant

Contract

Person

BankAcc.

*

Address*

partnerPartner

Role{abs}

account

PostalAddr.E-Mail

• Splitting Classes (for example: Address >>> Address/PostalAddress)

• Adding Classes and Associations (for example.: E-Mail)




Contractpartner

Partner

Person

BankAcc.

*

Address*

Role{abs}

account

PostalAddr.E-Mail

• Removing Classes and Associations (for example: Claim, Claimant) • Gluing Classes (for example: Partner/Role >>> Role)

Role

partner

Refactoring Information SystemsRefactoringInformation Systems


Information System Example

Contract

Claim

partner

claimant

inAcc

outAcc

inAcc

outAccContract

Claim

partner

claimant

Role

Address

Person

BankAcc.

*

*

:Person:BankAcc.

:BankAcc.

:inAcc

:outAcc:Contract

:partner

:Person:BankAcc.

:BankAcc.

:inAcc

:outAcc

:Contract:partner:Role


Informations Sys. Example (cont.)

inAcc.

outAcc.

partner

claimant

*

*

Role

Contract

Person

BankAcc.

*

Address*

Claim

inAcc.

outAcc.

partner

claimant

*

*

Partner

Claimant

{abs}

:Person:BankAcc.

:BankAcc.

:outAcc

:inAcc:Contract:partner:Role

:Person:BankAcc.

:BankAcc. :inAcc

:outAcc :Contract:partner:Role:Role

:Partner:Clai.



Contract

Person

BankAcc.

*

Address*

Claim

partner

claimant

Partner

Claimant

Role{abs}

inAcc.

outAcc.

account

:Person:BankAcc.

:BankAcc. :inAcc

:outAcc :Contract:partner:Role:Role

:Partner:Clai.

:Person

:BankAcc.

:BankAcc.

:Contract:partner:Role:Role

:Partner:Clai.

:account

:account




Contract

Person

BankAcc.

*

Address*

partnerPartner

Role{abs}

account

PostalAddr.E-Mail

:Person

:Address

:Address

:Address

:Person

:Address

:Address

:Address

: PostalAddr.

:PostalAddr.

: PostalAddr.


:Claimant :Claim



Contractpartner

Partner

Person

BankAcc.

*

Address*

Role{abs}

account

PostalAddr.E-Mail

Role

partner

:Person :Role

:Person :Role

:Partner:BankAcc :Contract:Role


SummaryRefactoring

Semantics preserving change of system structures

Information SystemsSoftware Systems with (huge) Databases

Refactoring Information SystemsSemantics preserving change of a

system structure together with the structure of the existing data

(Agile Database Development, Agile Maintenance, ...)


Comparable SituationsClass Model and Object WorldMeta-Model and Model InstancesDatabase Schema and Database TablesXML-Schema and XML-DocumentsBusiness Process Models and (Running) ProcessesProgramms and (Running) Threads(Software-) Products and (Sold) Instances......


Current SituationTactics in the running system: Don‘t touch the data!

– Changes above the persistence level only– Usage of mapping tools (z. B. Hibernate)– Sometimes reinterpretation of the data in the old model

(usage of comment fields, change of field types, several information encode in same field, ...)

Strategy for new Systems: Hand-Programmed Migration– Complete migration of data from the old to the new application– Cost: 1/3 Development, 1/3 Migration und 1/3 Introduction &

Teaching– Production break

Quality of data structures worse than expected, development cost higher than expected


Meta-Model

Agile DB-Development

System: V3 System: V4

Database 3

System: V1

Database 1

System: V2

Database 2

System: V3 System: V4

Delta 3

System: V1

Database 1

System: V2

Delta 2


What do we need?Adding Classes and AssociationsDeleting Classes and AssociationsSplitting Classes and Associations

(copy)Gluing Classes and AssociationsRedirecting and Distributing

Associations


Meta-ModelGraphs „live“ in the algebraic categorie:

Sorts : Object Opns : source, target: Object → Object .

A Model M is a Graph.

A (typed) Database is a morphisms i: I M

PartnerClaimant

Role{abs}

Role


Contract

Person

BankAcc.

*

Address*

Claim

partner

clai.

Partner

Claimant

Role{abs}

acc.

p1p2

p3p4

p5

a1

a2

o1

o2

c1

c2

b1

b2

Model and Database


RefactorisationA Refactorisation is a pair: (le:R M, ri:R N),

thatdeletes objects not in the image of le,adds nothing (!!!) (Defaults ???),renames preserved objects along le and ri, splits objects with several preimages under le,glues objects that are identified by ri.

A Migration of a typed database along a Refactorisation(le: R M, ri: R N):

rileM R N

I X J

i j x

ri'le'

(PB) (PB)


Pullback-Complement

1

2 3

1

2 ,3

1

21

31

f

f1*

f2

*

g

22

32

1

21,3

22

2,3

1

1

21,3

12

2,3

2

g1 *

g2 *

A

B C

D1

D2

(g, f1*) PB of (f, g1*),

(g, f2*) PB of (f, g2*), and

D1* D2* implies

(g, f) without unique PBC-----------------------------------But: f is surjectivecompare:• Meisen 1973• Bauderon 2001


„Archaic“ Form

1234

12

34

1234

1324

1423

f

f1*

f 2*

g1 *

g2 *g

i1 ::= 13 14, 24 23

i2 ::= 13 23, 24 14

-----------------------------

i1 f2* f1*

i2 f2* f1*


Component-Graphs CG(Component-)Graph ::= g: G G (g generates components

on G)

Morphisms ::= t : (i: I I) (m: M M) = (t: I M, t: I M) with t i = m t

Model ::= (Component) Graph m: M M Database ::= (Component Graph) Morphisms t: i m

Such that t is bijective on i-1(p) to m-1(t(p)) for all p I.

Refactorisation ::= (l: k m, r: k n)Such that l and r injective.

Refactorisations are injective where databases are not and vice versa

1,2,a

3,4,5,d,e

6,7,8,h

b c

f,g

g: G Gg: G G

1

2

5

6

8

7

4

a

d

ef

h

g

b

3 c


Migration : Double-Pullback, such that v is Database !

Pullbacks preserve Databases!Let x be short for x : X X!

• r‘ ::= idX; J = X

• v ::= r w

::= ker(x) ker (r w)

• J = X|• r‘ ::= • j and v as diagram completions, since ker(r w) and

ker(x)

CG-Migration

rlm k n

i x j

t v w

r'l'

(PB) (PB)


Inheritance Partial Components

objA:A

objC:C

Class A

Class DClass CClass B

Class E Class F

Model Instance

objA:A

objC:CobjB:B

objE:E

objA:A

objD:D

objF:F


Pullback Complement Defect

1

2

1

3

1

f

f*

g

g*

Morphisms f and g are given.g* f* = f g implies, that

there is a node 1 with:• f*(1) = 1 and• g*(1) = 3

f(1) = f(2) = g*(1) and (g, f*) pullback of (f, g*) implies:• Pullback contains at least 2

elements

No pullback complement !!!

PB


A database v:c a satisfies: c(x) = c(y) v(x) = v(y) x = y

The pair(w, g) is Folding of database v and refactorisation f, if

• w is database,• w g = f v,• (g, g) is epimorphism, and

g = kern(f v) kern(c).

It is Abstract Folding, if for all (a: c x, b: c y, t: y x), such that t is database and a f v = t b, there is unique u: d y with(1) u g = b und (2) t u = a w.

(Abstract) Folding

a b

c dg

f

v w

a b

c dg

f

v w

u

xa

y

t

b


ResultsFoldings are abstract Foldings.Abstract Foldings are unique up to

isomorphism.Abstract Foldings

– can be composed and– decomposed as pushouts.

A refactorisation inducesan unique migration, if

– left side is pullback and– right side is abstract Folding.

rlm k n

i x j

t v w

r'l'

(PB) (AF)


Formalized Examples

Address

Person

BankAcc.

*

*

Contract

Claim

partner

claimant

inAcc.

outAcc.

Address

Person

BankAcc.

*

*

inAcc.

outAcc.Contract

Claim

partner

claimant

Role

Left:

Middle:

Right:

ID


Formalized Examples

Left Middle Right

Role

PartnerinAcc

Role

Partner

inAccHELPER

Role

Partner

inAcc

Shift of Associations


Formalized Examples

Role

Left

part

ner

claim

ant

pers

on

inA

cc

outA

cc

Middle Right

Role

Partner Claimantpers

on

pers

on

inA

cc

outA

cc

claim

ant

part

ner

RoleRole

Partner Claimant

pers

on

inA

cc

outA

cccl

aim

ant

part

ner

Cloning of Objects

Role


Sequential Composition

M R r1

l1 S P

r2l

2

N

Ul2' r

1'

( P B )

The sequential composition (l1, r1) (l2, r2) = (l1 l2‘, r2 r1‘) is given by the pullback of r1 and l2.

The sequential composition is well-defined, since pullbacks preserve refactorisation-morphisms.


R2(R1(t)) = R2 R1(t)

M K

J

N

P Hl

1

p1

p2

r

1

l2

r2

D F

I

E

B Cl

1'

p1' p

2'

r1'

l2'

r2'

t v1

u2

u1

v2 w


Additional ResultsAll constructions work for arbitrary refactorisations.

(Non-injective component mapping. Already used in the examples above!)

The database property is preserved by pullbacks.

The (abstr.) folding along refactorisation r: K R is a free construction wrt. the pullback functor P: DR DK from the R-typed databases to the K-typed databases.

It is the composition of the (trivial) free construction wrt. the pullback functor and the free construction from all arrows under R into the subcategory of all databases under R.

A whole migration step is a single free construction.


Current WorkMore practical examplesProviding constructions for default values (null)Finding atomic refactorisation steps for

Decomposition of refactorisationsParallel execution of refactorisations

Development of a prototype system (meta model)Checking practical examplesMigration-on-demandTransformations into concrete RDBMS (Oracle)

Schema extractionTrigger and Stored Procedures for lazy migration

Migration of the behaviour given by graph transformations

Refactoring Information Systems Michael Löwe, FHDW Hannover Oldenburg, January 9, 2007.

Documents

Transcript of Refactoring Information Systems Michael Löwe, FHDW Hannover Oldenburg, January 9, 2007.