1 / 37

Refactoring Information Systems

Refactoring Information Systems. Michael Löwe, FHDW Hannover Oldenburg, January 9, 2007. Contents. Motivating 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

stacey
Download Presentation

Refactoring Information Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Contents Motivating 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 Oldenburg

  3. Refactoring Information Systems Information Systems Refactoring

  4. inAcc. partner BankAcc. inAcc. outAcc. partner * Contract Role Claim Person Claim Contract outAcc. * Address claimant claimant Refactoring Example • Splitting Classes(for example: Person >>> Person / Role) • Redirecting Associations(for example: partner : Person >>> Role) Oldenburg

  5. partner Person Role Partner Claimant {abs} * inAcc. Contract inAcc. partner BankAcc. outAcc. * Claim Address claimant outAcc. claimant Refactoring Example (cont.) • Introducing Inheritance(for example: Role >>> Partner/Claimant) • Redirecting Associations(for example: inAcc and outAcc) Oldenburg

  6. Claimant Partner account inAcc. outAcc. Refactoring Example (cont.) Person * Role BankAcc. {abs} partner * Contract Address Claim claimant • Shifting Associations(for example: up the inheritance hierarchy) • Abstracting Associations(for ex.: inAcc and outAcc into account) Oldenburg

  7. Partner PostalAddr. E-Mail Refactoring Example (cont.) Person * account Role BankAcc. {abs} * Address partner Contract Claimant Claim claimant • Splitting Classes(for example: Address >>> Address/PostalAddress) • Adding Classes and Associations (for example.: E-Mail) Oldenburg

  8. Person Role Claimant Partner {abs} * account BankAcc. PostalAddr. Contract E-Mail partner partner Role * Address Claim claimant Refactoring Example (cont.) • Removing Classes and Associations (for example: Claim, Claimant) • Gluing Classes (for example: Partner/Role >>> Role) Oldenburg

  9. Refactoring Information Systems Information Systems Refactoring

  10. partner inAcc partner BankAcc. inAcc outAcc * Claim Contract Role Contract Person Claim outAcc * Address claimant claimant :inAcc :partner :Role :BankAcc. :Person :Contract :BankAcc. :outAcc Information System Example :inAcc :partner :BankAcc. :Person :Contract :outAcc :BankAcc. Oldenburg

  11. * partner Person Role Claimant Partner {abs} * * inAcc. Contract inAcc. partner BankAcc. * outAcc. * Claim Address * outAcc. claimant claimant :BankAcc. :BankAcc. :Person :Person :Role :Role :Contract :Clai. :Partner :Contract :partner :outAcc :BankAcc. :inAcc Informations Sys. Example (cont.) :outAcc :partner :Role :inAcc :BankAcc. Oldenburg

  12. Person * Role BankAcc. Partner Claimant {abs} account partner * Contract Address inAcc. Claim claimant outAcc. :BankAcc. :BankAcc. :Person :Person :Contract :Clai. :Partner :Role :Clai. :Contract :Role :Role :Partner :Role :account :partner :BankAcc. :account Informations Sys. Example (cont.) :partner :outAcc :BankAcc. :inAcc Oldenburg

  13. Partner E-Mail PostalAddr. : PostalAddr. :PostalAddr. :Address :Address :Person :Person :Address :Address :Address : PostalAddr. :Address Informations Sys. Example (cont.) Person * account Role BankAcc. {abs} * Address partner Contract Claimant Claim claimant Oldenburg

  14. Person Role Claimant Partner {abs} * account BankAcc. E-Mail PostalAddr. Contract partner partner Role * Address Claim claimant :Role :Partner :BankAcc :Person :Role :Role :Contract :Claim :Claimant :Person Informations Sys. Example (cont.) Oldenburg

  15. Summary Refactoring Semantics preserving change of system structures Information Systems Software Systems with (huge) Databases Refactoring Information Systems Semantics preserving change of a system structure together with the structure of the existing data (Agile Database Development, Agile Maintenance, ...) Oldenburg

  16. Comparable Situations Class Model and Object World Meta-Model and Model Instances Database Schema and Database Tables XML-Schema and XML-Documents Business Process Models and (Running) Processes Programms and (Running) Threads (Software-) Products and (Sold) Instances ...... Oldenburg

  17. Current Situation Tactics 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 Oldenburg

  18. System: V1 System: V1 System: V2 System: V2 System: V3 System: V3 System: V4 System: V4 Database 1 Database 1 Database 3 Delta 2 Delta 3 Agile DB-Development Database 2 Meta-Model Oldenburg

  19. What do we need? Adding Classes and Associations Deleting Classes and Associations Splitting Classes and Associations (copy) Gluing Classes and Associations Redirecting and Distributing Associations Oldenburg

  20. Partner Claimant Role Role Meta-Model Graphs „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 {abs} Oldenburg

  21. Person * acc. BankAcc. Claimant Partner {abs} Role partner * Contract Address Claim clai. b1 p5 c2 b2 p1 p3 c1 p2 a1 a2 o1 o2 p4 Model and Database Oldenburg

  22. le ri M R N i x j (PB) (PB) I X J le' ri' Refactorisation A Refactorisation is a pair: (le:R  M, ri:R  N), that deletes 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): Oldenburg

  23. Pullback-Complement • (g, f1*) PB of (f, g1*), • (g, f2*) PB of (f, g2*), and • D1*  D2* implies • (g, f) without unique PBC • ----------------------------------- • But: f is surjective • compare: • Meisen 1973 • Bauderon 2001 Oldenburg

  24. „Archaic“ Form f 12 1234 i1 ::= 13  14, 24  23 i2 ::= 13  23, 24  14 ----------------------------- i1 f2*  f1* i2 f2*  f1* 34 g2* g g1* 13 f2* 24 1 2 3 f1* 4 14 23 Oldenburg

  25. 1 a 1,2,a b 2 b c c 3 g: G G d 3,4,5,d,e 4 5 e g f,g f 6 6,7,8,h h 7 8 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 Oldenburg

  26. l r m k n t w v (PB) (PB) i x j l' r' CG-Migration • Migration : Double-Pullback, such that vis 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)   Oldenburg

  27. Model Instance Class A objA:A objA:A objA:A Class B Class C Class D objB:B objC:C objC:C objD:D Class E Class F objE:E objF:F Inheritance  Partial Components Oldenburg

  28. Pullback Complement Defect • 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 Oldenburg

  29. f a b v w g c d a x t u y b (Abstract) Folding • 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. f a b v w g c d Oldenburg

  30. l r m k n t w v (PB) (AF) i x j l' r' Results Foldings are abstract Foldings. Abstract Foldings are unique up to isomorphism. Abstract Foldings • can be composed and • decomposed as pushouts. A refactorisation induces an unique migration, if • left side is pullback and • right side is abstract Folding. Oldenburg

  31. partner BankAcc. BankAcc. * Person Claim Contract Claim Role Person Contract * Address claimant Formalized Examples inAcc. outAcc. Left: inAcc. partner outAcc. * Middle: * ID Address claimant Right: Oldenburg

  32. Formalized Examples Shift of Associations Left Middle Right inAcc Role Role Role inAcc HELPER inAcc Partner Partner Partner Oldenburg

  33. Formalized Examples Cloning of Objects Left Middle Right claimant claimant partner partner partner claimant Role Role Role Role Role Partner Claimant Partner Claimant person person outAcc person outAcc person outAcc inAcc inAcc inAcc Oldenburg

  34. Sequential Composition 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. Oldenburg

  35. R2(R1(t)) = R2 R1(t) Oldenburg

  36. Additional Results All 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: DR  DK 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. Oldenburg

  37. Current Work More practical examples Providing constructions for default values (null) Finding atomic refactorisation steps for Decomposition of refactorisations Parallel execution of refactorisations Development of a prototype system (meta model) Checking practical examples Migration-on-demand Transformations into concrete RDBMS (Oracle) Schema extraction Trigger and Stored Procedures for lazy migration Migration of the behaviour given by graph transformations Oldenburg

More Related