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 hoc way

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 ChAcc extends Account {}

sig SavAcc extends 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

ChAcc

!

ChAcc

Account Customerowner

Account Customer

chOwner

owner

!

7

Introduce Relation Law (Law 2)

(↔) if r belongs to ∑ then v contains the r→exp item;

(→) The family of S in ps does not declare r;

(←) r does not appear in ps and forms.

pssig S {

rs}fact F {

forms}

pssig S {

rs,r : set T

}fact F {

formsr = exp

}

=∑,v

8

Equivalence Notion

=∑,v

∑ = {Bank, accounts, Account}

v = {(accounts → col.elems)}

AccountBankaccounts

Bank

Account

Vectorcol

elems

Alphabet

View

9

Example: Pull Up Relation (Law 3)

no (Account-ChAcc).chOwner

=∑,v

ChAcc

?

Account

!

Customer

ChAcc chOwner

CustomerAccountowner

10

Introduce Formula Law (Law 4)

provided

(↔) The formula f can be deduced from the formulas in ps and forms.

psfact F {

forms}

psfact F {

formsf

}

=∑,v

11

Bank System Atomization

Law 2 (→) Law 4 (→) Law 3 (←)

Law 4 (→)Law 4 (→)Law 2 (←)

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 =∑,v ...M2 Mn

Component

Syntactic conditions

13

Conclusions

Axiomatic semanticsOptimize analysis

Substitute ComponentsDerive 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

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 pssig S {}

Set of paragraphs

=∑,v

17

Pull Up Relation Lawpssig T { rs}sig S extends T { rs’, r : set U}fact F { forms}

pssig 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

psfact F {

formsf

}fact G {

forms’}

psfact F {

forms}fact G {

forms’f

}

=∑,v

19

Split Relation Lawpssig S { rs, r : set T}fact F { forms}

pssig 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 r→u.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

Introduce a Generalization Lawpssig S { rs }sig T { rs’ }fact F { forms}

pssig 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

Change Relation Qualifier Type: from set to one Law

pssig S {

rs,r : set T

}fact F {

formsall s: S | one s.r

}

pssig S {

rs,r : one T

}fact F {

forms}

=∑,v

22

Example: Split Relation

Bank Accountaccounts

Bank

Vector

Accountaccounts

col

elem ents

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;

(→) ps does not declare any paragraph named C;

(←) C does not appear in ps, rs, rs’ and forms.

26

Inserting a Collection Refactoring

BAr

A

B

CollectionrCol

elements=∑,v

27

A C

B

b

acB

CA

b

c

!

! !

!

Moving a Relation Refactoring

=∑,v

28

Extending a Signature

Constraint S in T

Formula deduced (S in T) => (#S <= #T)

S

T

S

T

#S = 5 && #T = 3=∑,v

29

Inserting a Relation

Constraint all s: S | one s.r

Formula deduced (#S != 0) => (#T > 0)

S T!

rS T

#S != 0 && #T = 0

=∑,v

30

T

S U S

T

Ur r

t

! !

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 T t=r

=∑,v