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

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

3. 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. 4 Alloy sig Bank { accounts: set Account } sig Account {} sig ChAcc extends Account {} sig SavAcc extends Account {} fact AccPartition { Account = ChAcc + SavAcc }

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

6. 6 Example: Introduce Relation =,v

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

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

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

10. 10 Introduce Formula Law (Law 4) provided () The formula f can be deduced from the formulas in ps and forms. ps fact F { forms } ps fact F { forms f } =,v

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

12. 12 Components: Specification Matching public class DBHandler { private static OleDbConnection connection; public static 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; } M1 =,v... M2Mn Component Syntactic conditions

13. 13 Conclusions Axiomatic semantics Optimize analysis Substitute Components Derive refactorings

14. 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. 15 Basic Laws of Object Modeling Rohit Gheyi Tiago Massoni Paulo Borba Software Productivity Group http://www.cin.ufpe.br/spg Informatics Center – UFPE http://www.cin.ufpe.br/spg

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

17. 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. 18 Move Formula Law ps fact F { forms f } fact G { forms } ps fact F { forms } fact G { forms f } =,v

19. 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 } () if r belongs to then v contains the ru.t item;... () ps does not declare any paragraph named U; the family of S does not declare any relation named u in ps; () U, t and u do not appear in ps, rs and forms. =,v

20. 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 } () if U belongs to then v contains the U(S+T) item; () ps does not declare any paragraph named U and the family of S and T does not declare any relation with the same name in ps () U, S and T do not appear in ps, rs, rs and forms. =,v

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

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

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

24. 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. 25 Extract Interface Refactoring () if C belongs to then v contains the CB item; () ps does not declare any paragraph named C; () C does not appear in ps, rs, rs and forms.

26. 26 Inserting a Collection Refactoring =,v

27. 27 Moving a Relation Refactoring =,v

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

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

30. 30 Inserting a Relation in a Subsignature 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) some s:S | s !in Tt=r =,v