Three-Tier Architecture
description
Transcript of Three-Tier Architecture
![Page 1: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/1.jpg)
CS 290C: Formal Models for Web Software
Lecture 9: Analyzing Data Models Using Alloy Analyzer and SMT-Solvers
Instructor: Tevfik Bultan
![Page 2: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/2.jpg)
Three-Tier Architecture
Backend Database
Browser
Web Server
![Page 3: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/3.jpg)
Three-Tier Arch. + MVC Pattern
Backend Database
Browser
Model
ViewsController
Web Server
• MVC pattern has become the standard way to structure web applications:
• Ruby on Rails• Zend for PHP• CakePHP• Struts for Java• Django for Python• …
![Page 4: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/4.jpg)
Benefits of the MVC-Architecture
• Benefits of the MVC architecture:• Separation of concerns • Modularity• Abstraction
• These are the basic principles of software design• Can we exploit these principles for analysis?
![Page 5: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/5.jpg)
A Data Model Verification Approach
MVC Design Principles
Automatic Extraction
Add data model properties
![Page 6: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/6.jpg)
Rails Data Models
• Data model verification: Analyzing the associations/relations between data objects
• Specified in Rails using association declarations inside the ActiveRecord files– The basic relation types
• One-to-one• One-to-many• Many-to-many
– Extensions to the basic relations using Options• :through, :conditions, :polymorphic, :dependent
![Page 7: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/7.jpg)
The Three Basic Relations in Rails• One-to-One (One-to-ZeroOrOne)
.
• One-to-Many
class User < ActiveRecord::Base has_one :accountend.
class Account < ActiveRecord::Base belongs_to :userend
class User < ActiveRecord::Base has_many :projectsend.class Project < ActiveRecord::Base belongs_to :userend
User
Account0..1
User
Project*
1
1
![Page 8: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/8.jpg)
The Three Basic Relations in Rails
• Many-to-Manyclass Author < ActiveRecord::Base has_and_belongs_to_many :booksend
class Book < ActiveRecord::Base has_and_belongs_to_many :authorsend
Author
Book
*
*
![Page 9: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/9.jpg)
Options to Extend the Basic Relations
• :through Option– To express transitive relations, or – To express a many-to-many relation using a join model
as opposed to a join table
• :conditions Option– To relate a subset of objects to another class
• :polymorphic Option– To express polymorphic relations
• :dependent Option– On delete, this option expresses whether to delete the
associated objects or not
![Page 10: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/10.jpg)
The :through Option
class Book < ActiveRecord::Basehas_many :editionsbelongs_to :author
end
class Author < ActiveRecord::Basehas_many :bookshas_many :editions, :through => :books
end
class Edition < ActiveRecord::Base belongs_to :bookend Book
Author Edition
*
*
* 1
11
![Page 11: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/11.jpg)
The :conditions Option
class Account < ActiveRecord::Base has_one :address,
:conditions => “address_type=‘Billing”end.class Address < ActiveRecord::Base belongs_to :accountend
AddressAccount address_type=
‘Billing’
0..11
![Page 12: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/12.jpg)
The :polymorphic Option
class Address < ActiveRecord::Base belongs_to :addressable, :polymorphic => trueend
class Account < ActiveRecord::Base has_one :address, :as => :addressableend
class Contact < ActiveRecord::Base has_one :address, :as => :addressableend
Account
Address
Contact
0..1
0..1
1
1
![Page 13: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/13.jpg)
The :dependent Option
• :delete directly deletes the associated objects without looking at its dependencies
• :destroy first checks whether the associated objects themselves have associations with the :dependent option set
class User < ActiveRecord::Base has_many :contacts, :dependent => :destroyend
class Contact < ActiveRecord::Base belongs_to :user has_one :address, :dependent => :destroyend
AddressContactUser *1 1 0..1
![Page 14: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/14.jpg)
Formalizing Rails Semantics
Formal data model: M = <S, C, D>• S: The sets and relations of the data model (data model
schema)– e.g. {Account, Address, Project, User} and the relations
between them• C: Constraints on the relations
– Cardinality constraints, transitive relations, conditional relations, polymorphic relations
• D: Dependency constraints express conditions on two consecutive instances of a relation such that deletion of an object from the fist instance leads to the other instance
![Page 15: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/15.jpg)
Formalizing Rails Semantics
• Data model instance: I = <O,R> where O = {o1, o2, . . . on} is a set of object classes and R = {r1, r2, . . . rm} is a set of object relations and for each ri ϵ R there exists oj, ok ϵ O such that ri oj × ok
• I = <O,R> is an instance of the data model M = <S,C,D>, denoted by I |= M,if and only if – the sets in O and the relations in R follow the schema
S, and – R |= C
![Page 16: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/16.jpg)
Formalizing Rails Semantics
• Given a pair of data model instances I = <O,R> and I’ = <O’,R’>, (I, I’) is a behavior of the data model M = <S,C,D>, denoted by (I, I’) |= M, if and only if – O and R and O’ and R’ follow the schema S– R |= C and R’ |= C, and – (R,R’) |= D
![Page 17: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/17.jpg)
Data Model Properties
Given a data model M = <S,C,D>, we define four types of properties:
• state assertions (AS): properties that we expect to hold for each instance of the data model
• behavior assertions (AB): properties that we expect to hold for each pair of instances that form a behavior of the data model
• state predicates (PS): predicates we expect to hold in some instance of the data model
• behavior predicates (PB): predicates we expect to hold in some pair of instances that form a behavior of the data model
![Page 18: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/18.jpg)
Data Model Properties
![Page 19: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/19.jpg)
Data Model Verification
• The data model verification problem: Given a data model property, determine if the data model satisfies the property.
• An enumerative (i.e., explicit state) search technique not likely to be efficient for bounded verification
• We can use SAT-based bounded verification!– Main idea: translate the verification query to a Boolean
SAT instance and then use a SAT solver to search the state space
![Page 20: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/20.jpg)
Data Model Verification
• SAT-based bounded verification: This is exactly what the Alloy Analyzer does!
• Alloy language allows specification of objects and relations, and the specification of constraints on relations using first-order logic
• In order to do bounded verification of Rails data models, automatically translate the Active Record specifications to Alloy specifications
![Page 21: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/21.jpg)
Translation to Alloy
class ObjectA has_one :objectBend.
class ObjectA has_many :objectBsend.
class ObjectA belongs_to :objectBend.
class ObjectA has_and_belongs_to_many
:objectBsend
.sig ObjectA { objectB: lone ObjectB}.
sig ObjectA { objectBs: set ObjectB}.
sig ObjectA { objectB: one ObjectB}.
sig ObjectA { objectBs: set ObjectB }fact { ObjectA <: objectBs =
~(ObjectB <: objectA }
ALLOY:RAILS:
![Page 22: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/22.jpg)
Translating the :through Option
class Book < ActiveRecord::Base has_many :editions belongs_to :authorend
class Author < ActiveRecord::Base has_many :books has_many :editions,
:through => :booksend
class Edition < ActiveRecord::Base belongs_to :bookend
sig Book { editions: set Edition, author: one Author}
sig Author { books: set Book, editions: set Edition} { editions = books.editions}
sig Edition { book: one Book}
fact { Book <: editions = ~(Edition <: book) Book <: authors = ~(Author <: book)}
Book
Author Edition
*
**
11
1
![Page 23: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/23.jpg)
Translating the :dependent Option
• The :dependent option specifies what behavior to take on deletion of an object with regards to its associated objects
• To incorporate this dynamism, the model must allow analysis of how sets of objects and their relations change from one state to the next
class User < ActiveRecord::Base has_one :accountend
.
class Account < ActiveRecord::Base belongs_to :user,
:dependent => :destroyend
sig User {}sig Account {}one sig PreState { accounts: set Account, users: set User, relation1: Account lone -> one User}one sig PostState { accounts’: set Account, users’: set User, relation1’: Account set -> set User}
![Page 24: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/24.jpg)
Translating the :dependent Option
– We also update relations of its associated object(s) based on the use of the :dependent option
pred deleteAccount [s: PreState, s’: PostState, x: Account] { all x0: Account | x0 in s.accounts all x1: User | x1 in s.users s’.accounts’ = s.accounts - x s’.users’ = s.users s’.relation1’ = s’.relation1 – (x <: s.relation1)}
![Page 25: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/25.jpg)
Translating the :dependent Optionpred deleteContext [s: PreState, s': PostState, x:Context] { all x0: Context | x0 in s.contexts all x1: Note | x1 in s.notes all x2: Preference | x2 in s.preferences all x3: Project | x3 in s.projects all x4: RecurringTodo | x4 in s.recurringtodos all x5: Tag | x5 in s.tags all x7: Todo | x7 in s.todos all x8: User | x8 in s.users s'.contexts' = s.contexts - x s'.notes' = s.notes s'.preferences' = s.preferences s'.projects' = s.projects s'.recurringtodos' = s.recurringtodos s'.tags' = s.tags s'.todos' = s.todos - x.(s.context_todos) s'.users' = s.users
s'.notes_user' = s.notes_user s'.completed_todos_user' = s.completed_todos_user s'.recurring_todos_user' = s.recurring_todos_user s'.todos_user' = s.todos_user - (x.(s.context_todos) <: s.todos_user) s'.active_contexts_user' = s.active_contexts_user s'.active_projects_user' = s.active_projects_user s'.projects_user' = s.projects_user s'.contexts_user' = s.contexts_user - (x <: s.contexts_user) s'.recurring_todo_todos' = s.recurring_todo_todos - (s.recurring_todo_todos :> x.(s.context_todos)) ...
![Page 26: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/26.jpg)
Verification Overview
Data Model Properties
Active Records
Alloy Specification
Verified
Counter-example
Data Model
Instance
TranslatorAlloy
Analyzer
![Page 27: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/27.jpg)
Experiments
• We used two open-source Rails applications in our experiments:– TRACKS: An application to manage things-to-do lists– Fat Free CRM: Customer Relations Management
software
• We wrote 10 properties for TRACKS and 20 properties for Fat Free CRM
TRACKS Fat Free CRMLOC 6062 lines 12069 lines
Data model classes
13 classes 20 classes
Alloy spec LOC 301 lines 1082 lines
![Page 28: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/28.jpg)
Types of Properties Checked
• Relationship Cardinality– Is an Opportunity always
assigned to some Campaign?• Transitive Relations
– Is a Note’s User the same as the Note’s Project’s User?
• Deletion Does Not Cause Dangling References– Are there any dangling Todos after a User is deleted?
• Deletion Propagates to Associated Objects– Does the User related to a Lead still exist
after the Lead has been deleted?
Note
User Project
![Page 29: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/29.jpg)
Experimental Results
• Of the 30 properties we checked 7 of them failed• For example, in TRACKS Note’s User can be different than
Note’s Project’s User– Currently being enforced by the controller– Since this could have been enforced using the :through
option, we consider this a data-modeling error• Another example from TRACKS: User deletion creates
dangling Todos
– User deletion does not get propagated into the relations of the Context object, including the Todos
ContextUser Todo* *1 1
:dependent => :delete
![Page 30: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/30.jpg)
Performance
• To measure performance, we recorded – the amount of time it took for Alloy to run and check the properties– the number of variables generated in the boolean formula
generated for the SAT-solver• The time and number of variables are averaged over the
properties for each application• Taken over an increasing bound, from at most 10 objects for
each class to at most 35 objects for each class
![Page 31: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/31.jpg)
Summary
• An approach to automatically discover data model errors in Ruby on Rails web applications
• Automatically extract a formal data model, verify using the Alloy Analyzer
• An automatic translator from Rails ActiveRecords to Alloy– Handles three basic relationships and several options
(:through, :conditions, :polymorphic, :dependent)• Found several data model errors on two open source
applications• Bounded verification of data models is feasible!
![Page 32: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/32.jpg)
What About Unbounded Verification?
• Bounded verification does not guarantee correctness for arbitrarily large data model instances
• Is it possible to do unbounded verification of data models?
![Page 33: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/33.jpg)
An Approach for Unbounded Verification
MVC DesignPattern
Automatic Extraction
AutomaticTranslation +AutomaticProjection+Properties
![Page 34: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/34.jpg)
Another Rails Data Model Example
class User < ActiveRecord::Basehas_and_belongs_to_many :roleshas_one :profile, :dependent => :destroyhas_many :photos, :through => :profileendclass Role < ActiveRecord::Basehas_and_belongs_to_many :usersendclass Profile < ActiveRecord::Base belongs_to :user has_many :photos, :dependent => :destroy has_many :videos, :dependent => :destroy, :conditions => "format='mp4'"endclass Tag < ActiveRecord::Basebelongs_to :taggable, :polymorphic => trueendclass Video < ActiveRecord::Base belongs_to :profile has_many :tags, :as => :taggableendclass Photo < ActiveRecord::Base ...
Role
*
0..1
1
User
Profile
*
1
Video
*
1
Taggable
*
Tag
1
* 1Photo
*
1
format=.‘mp4’
![Page 35: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/35.jpg)
Translation to SMT-LIB
• Given a data model M = <S, C, D> we translate the constraints C and D to formulas in the theory of uninterpreted functions
• We use the SMT-LIB format
• We need quantification for some constraints
![Page 36: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/36.jpg)
Translation to SMT-LIB
class Profile has_many :videosendclass Video belongs_to :profileend
(declare-sort Profile 0)(declare-sort Video 0)(declare-fun my_relation (Video) Profile).
SMT-LIB:
RAILS:
• One-to-Many Relation
![Page 37: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/37.jpg)
Translation to SMT-LIB
class User has_one :profileendclass Profile belongs_to :userend
(declare-sort User 0)(declare-sort Profile 0)(declare-fun my_relation (Profile) User).(assert (forall ((x1 Profile)(x2 Profile)) (=> (not (= x1 x2)) (not (= (my_relation x1) (my_relation x2) ))) ))
SMT-LIB:
RAILS:
• One-to-One Relation
![Page 38: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/38.jpg)
Translation to SMT-LIB
class User has_and_belongs_to_many :rolesendclass Role has_and_belongs_to_many :usersend
(declare-sort Role 0)(declare-sort User 0)(declare-fun my_relation (Role User) Bool)
SMT-LIB:
RAILS:
Many-to-Many Relation
![Page 39: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/39.jpg)
Translating the :through Option
class Profile < ActiveRecord::Base belongs_to :user has_many :photosendclass Photo < ActiveRecord::Base belongs_to :profileEndclass User < ActiveRecord::Base has_one :profile has_many :photos, :through => :profileend
(declare-sort Profile 0)(declare-sort Photo 0)(declare-sort User 0)(declare-fun profile_photo (Photo) Profile)(declare-fun user_profile (Profile) User)(declare-fun user_photo (Photo) User)(assert (forall ((u User)(ph Photo)) (iff (= u (user_photo ph)) (exists ((p Profile)) (and (= u (user_profile p)) (= p (profile_photo ph)) )) )))
Profile
User Photo
0..1
**
11
1
![Page 40: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/40.jpg)
Translating the :dependent Option
• The :dependent option specifies what behavior to take on deletion of an object with regards to its associated objects
• To incorporate this dynamism, the model must allow analysis of how sets of objects and their relations change from one state to the next
class User < ActiveRecord::Base has_one :account,
:dependent => :destroyend
.
class Profile < ActiveRecord::Base belongs_to :userend
(declare-sort Profile 0)(declare-sort User 0)
(declare-fun Post_User (User) Bool)(declare-fun Post_Profile (Profile) Bool)
(declare-fun user_profile (Profile) User)(declare-fun Post_user_profile (Profile User) Bool)
![Page 41: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/41.jpg)
Translating the :dependent Option
– Update sets relations of its associated object(s) based on the use of the :dependent option
(assert (not (forall ((x User)) (=> (and (forall ((a User)) (ite (= a x) (not (Post_User a)) (Post_User a))) (forall ((b Profile)) (ite (= x (user_profile b)) (not (Post_Profile b)) (Post_Profile b) )) (forall ((a Profile) (b User)) (ite (and (= b (user_profile a)) (Post_Profile a)) (Post_user_profile a b) (not (Post_user_profile a b)) )) ) ;Remaining property-specific constraints go here)))
![Page 42: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/42.jpg)
Verification
• Once the data model is translated to SMT-LIB format we can state properties about the data model again in SMT-LIB and then use an SMT-Solver to check if the property holds in the data model
• However, when we do that, for some large models, SMT-Solver times out!
• Can we improve the efficiency of the verification process?
![Page 43: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/43.jpg)
Property-Based Data Model Projection
• Basic idea: Given a property to verify, reduce the size of the generated SMT-LIB specification by removing declarations and constraints that do not depend on the property
• Formally, given a data model M = <S, C, D> and a property p,
(M, p) = MP
where MP = S, C⟨ P, DP is the projected data model such ⟩that CP C and D⊆ P D⊆
![Page 44: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/44.jpg)
Property-Based Data Model Projection
• Key Property: For any property p, M |= p ⇔ (M, p) |= p
• Projection Input: Active Record files, property p• Projection Output: The projected SMT-LIB specification • Removes constraints on those classes and relations that
are not explicitly mentioned in the property nor related to them based on transitive relations, dependency constraints or polymorphic relations
![Page 45: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/45.jpg)
Data Model Projection: Example
Property, p: A User’s Photos are the same as the User’s Profile’s Photos.
Role
*
0..1
1
User
Profile
*
1
Video
*
1
Taggable
*
Tag
1
* 1Photo*
1
Data Model, M:
0..1
1
User
Profile* 1Photo*
1(M, p) =
![Page 46: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/46.jpg)
Verification Overview
Translator
SMT Solver (Z3)
Verified
Counter-example
Data Model Instance
Unknown
Formal Data Model
Data Model Properties
Projection
SMT-LIB Specification
![Page 47: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/47.jpg)
Experiments
• We used five open-source Rails apps in our experiments:– LovdByLess: Social networking site– Tracks: An application to manage things-to-do lists– OpenSourceRails(OSR): Social project gallery
application– Fat FreeCRM: Customer relations management software– Substruct: An e-commerce application
• We wrote 10 properties for each application
LovdBy
LessTracks OSR
Fat FreeCRM
Substruct
LOC 3787 6062 4295 12069 15639
Data Model Classes
13 13 15 20 17
![Page 48: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/48.jpg)
Types of Properties Checked
• Relationship Cardinality– Is an Opportunity always
assigned to some Campaign?• Transitive Relations
– Is a Note’s User the same as the Note’s Project’s User?
• Deletion Does Not Cause Dangling References– Are there any dangling Todos after a User is deleted?
• Deletion Propagates to Associated Objects– Does the User related to a Lead still exist
after the Lead has been deleted?
Note
User Project
![Page 49: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/49.jpg)
Experimental Results
• 50 properties checked, 16 failed, 11 were data model errors• For example in Tracks, a Note’s User can be different than
Note’s Project’s User– Currently being enforced by the controller– Since this could have been enforced using the :through
option, we consider this a data-modeling error• From OpenSourceRails: User deletion fails to propagate to
associated Bookmarks
– Leaves orphaned bookmarks in database– Could have been enforced in the data model by setting
the :dependent option on the relation between User and Bookmark
BookmarkUser*1
![Page 50: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/50.jpg)
Performance
• To measure performance, we recorded – The amount of time it took for Z3 to run and check the
properties– The number of variables produced in the SMT
specification• The time and number of variables are averaged over the
properties for each application
![Page 51: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/51.jpg)
Performance
• To compare with bounded verification, we repeated these experiments using the tool from our previous work and Alloy Analyzer– The amount of time it took for Alloy to run– The number of variables generated in the boolean
formula generated for the SAT solver– Taken over an increasing bound, from at most 10
objects for each class to at most 35 objects for each class
![Page 52: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/52.jpg)
Performance: Verification Time
![Page 53: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/53.jpg)
Performance: Formula Size (Variables)
Z3 Alloy
![Page 54: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/54.jpg)
Unbounded vs Bounded Performance
• Why does unbounded verification out-perform bounded so drastically?
Possible reasons:• SMT solvers operate at a higher level of abstraction than
SAT solvers• Z3 uses many heuristics to eliminate quantifiers in formulas• Implementation languages are different
– Z3 implemented in C++– Alloy (as well as the SAT Solver it uses) is implemented
in Java
![Page 55: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/55.jpg)
Summary
• Automatically extract a formal data model, translate it to the theory of uninterpreted functions, and verify using an SMT-solver– Use property-based data model projection for efficiency
• An automatic translator from Rails ActiveRecords to SMT-LIB– Handles three basic relationships and several options
(:through, :conditions, :polymorphic, :dependent)• Found multiple data model errors on five open source
applications– Unbounded verification of data models is feasible and
more efficient than bounded verification!
![Page 56: Three-Tier Architecture](https://reader035.fdocuments.in/reader035/viewer/2022062410/56815a9b550346895dc81a53/html5/thumbnails/56.jpg)
Possible Extensions
• Analyzing dynamic behavior– Model object creation in addition object deletion– Fuse the data model with the navigation model in order
to analyze dynamic data model behavior– Check temporal properties
• Automatic Property Inference– Manual property writing is error prone– Use the inherent graph structure in the the data model to
automatically infer properties about the data model• Automatic Repair
– When verifier concludes that a data model is violated, automatically generate a repair that establishes the violated property