Basic Laws of Object Modeling

1. Basic Laws of Object Modeling Rohit Gheyi Tiago Massoni Paulo Borba Software Productivity Grouphttp://www.cin.ufpe.br/spgInformatics Center – UFPE

2. Introduction • Semantics-preserving model transformations are usually proposed in an ad hocway • Simple mistakes may lead to incorrect transformations • introduce inconsistencies

3. Introduction • Modeling Laws • each law defines two transformations • have not been sufficiently studied yet • might bring similar benefits of programming laws • Reliability • Productivity • Identify, formalize and study modeling laws • Focus: modeling laws for Alloy earlier stages of the software development process

4. Alloy sig Bank { accounts: set Account } sig Account {} sig ChAccextends Account {} sig SavAccextends Account {} fact AccPartition { Account = ChAcc + SavAcc }

5. Basic Laws • We propose basic laws defining properties about: • signatures • facts • relations • Predicate calculus and relational operator properties are used here

6. Example: Introduce Relation =∑,v

7. Introduce Relation Law (Law 2) ps sig S { rs } fact F { forms } ps sig S { rs, r : set T } fact F { forms r = exp } =∑,v (↔) if r belongs to ∑ then v contains the r→exp item; (→) The family of S in ps does not declare r; (←) rdoes not appear in psand forms.

8. Equivalence Notion =∑,v Alphabet ∑= {Bank, accounts, Account} v = {(accounts → col.elems)} View

9. Example: Pull Up Relation (Law 3) no (Account-ChAcc).chOwner =∑,v

10. Introduce Formula Law (Law 4) ps factF { forms } ps factF { forms f } =∑,v provided (↔) The formula fcan be deduced from the formulas in psand forms.

11. Bank System Atomization Law 2 (→) Law 4 (→) Law 3 (←) Law 2 (←) Law 4 (→) Law 4 (→)

12. Components: Specification Matching Syntactic conditions M1 M2 Mn ... =∑,v =∑,v Component public class DBHandler { privatestatic OleDbConnection connection; publicstatic OleDbConnection Connection { get { if (connection == null) { string dataSource = "BancoCS.mdb"; string strConexao = "Provider= Microsoft.Jet.OLEDB.4.0; " + "Data Source=" + dataSource; connection = new OleDbConnection(strConexao); } return connection; } } public static void StartTransaction() { Connection.Open(); transaction = Connection.BeginTransaction(); } } public class DBHandler { private static OleDbConnection connection; public static void StartTransaction() { transaction = Connection.BeginTransaction(); } public static void main(String []args) { System.out.rintln(); connection = new OleDbConnection(strConexao); } public static OleDbConnection Connection { get { if (connection == null) { string dataSource = "BancoCS.mdb"; "Data Source=" + dataSource; } return connection; } } }

13. Conclusions Axiomatic semantics Optimize analysis Substitute Components Derive refactorings

14. Future Work • Propose more basic laws and refactorings • Show that our set of laws are complete • propose a normal form for Alloy • PVS (Prototype Verification System) • Model Refactoring X Code Refactoring

15. Basic Laws of Object Modeling Rohit Gheyi Tiago Massoni Paulo Borba Software Productivity Grouphttp://www.cin.ufpe.br/spg Informatics Center – UFPE

16. Introduce Empty Signature Law Set of paragraphs provided (→) psdoes not declare any paragraph named S;Sisnot in ∑; (←) Sdoes not appear in ps; if S is in ∑then v contains an item for S. ps ps sig S {} =∑,v

17. Pull Up Relation Law ps sig T { rs } sig S extends T { rs’, r : set U } fact F { forms } ps sig T { rs, r : set U } sig S extends T { rs’ } fact F { forms all t: T-S | no t.r } =∑,v

18. Move Formula Law ps factF { forms f } factG { forms’ } ps factF { forms } factG { forms’ f } =∑,v

19. Split Relation Law ps sig S { rs, r : set T } fact F { forms } ps sig S { rs, r : set T, u : set U } fact F { forms && r = u.t } sig U { t : set T } =∑,v (↔) if r belongs to ∑ then v contains the r→u.t item; ... (→) psdoes not declare any paragraph named U; the family of Sdoes not declare any relation named uin ps; (←) U, tand udo not appear in ps, rsand forms.

20. Introduce a Generalization Law ps sig S { rs } sig T { rs’ } fact F { forms } ps sig U {} sig S extends U{ rs } sig T extends U{ rs’ } fact F { forms U=S+T } =∑,v (↔) if U belongs to ∑ then v contains the U→(S+T) item; (→) psdoes not declare any paragraph named Uand the family of Sand Tdoes not declare any relation with the same name in ps (←) U, Sand Tdo not appear inps, rs, rs’ and forms.

21. Change Relation Qualifier Type: from set to one Law ps sig S { rs, r : setT } fact F { forms all s: S | one s.r } ps sig S { rs, r : oneT } fact F { forms } =∑,v

22. Example: Split Relation accounts = col.elements =∑,v ∑= {Bank, accounts, Account} v = {(accounts → col.elements)}

23. Example: Introduce a Generalization ∑= {ChAcc, SavAcc} v = {(Account → ChAcc+SavAcc)}

24. Introduce a Generalization Refactoring • Architects x Designers • All basic laws are very simple to apply since their pre-conditions are simple syntactic conditions

25. Extract Interface Refactoring (↔) if C belongs to ∑ then v contains the C→B item; (→) psdoes not declare any paragraph named C; (←) Cdoes not appear inps, rs, rs’ and forms.

26. Inserting a Collection Refactoring =∑,v

27. Moving a Relation Refactoring =∑,v

28. Extending a Signature • Constraint • S in T • Formula deduced • (S in T) => (#S <= #T) =∑,v #S = 5 && #T = 3

29. Inserting a Relation • Constraint • all s: S | one s.r • Formula deduced • (#S != 0) => (#T > 0) #S != 0 && #T = 0 =∑,v

30. Inserting a Relation in a Subsignature some s:S | s !in T t=r • Suppose s’ be an element that does not belong to T and relates with an element u’ of U in r • After including t=r, we have • (((s’->u’) in r) && (t = r)) =>((s’->u’) in t) =∑,v