Beanbag: Facilitating Model Inconsistency Fixing Yingfei Xiong Ph.D. Student Advisor: Zhenjiang Hu and Masato Takeichi University of Tokyo 1.

Slides:



Advertisements
Similar presentations
Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Advertisements

1/20 Generalized Symbolic Execution for Model Checking and Testing Charngki PSWLAB Generalized Symbolic Execution for Model Checking and Testing.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
An Introduction to Java Programming and Object- Oriented Application Development Chapter 8 Exceptions and Assertions.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Relational Algebra Chapter 4, Part A Modified by Donghui Zhang.
CMPT 354, Simon Fraser University, Fall 2008, Martin Ester 52 Database Systems I Relational Algebra.
ECE 331 – Digital System Design
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
1 Chapter 4 The Fundamentals of VBA, Macros, and Command Bars.
Hash Tables1 Part E Hash Tables  
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Relational Algebra Chapter 4, Part A.
1 Chapter 8 Object-Based Programming in VBA. 8 Chapter Objectives Declare and use object variables Create procedures that use built-in form methods Find.
1 Chapter 2 Reviewing Tables and Queries. 2 Chapter Objectives Identify the steps required to develop an Access application Specify the characteristics.
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Rutgers University Relational Algebra 198:541 Rutgers University.
Relational Algebra Chapter 4 - part I. 2 Relational Query Languages  Query languages: Allow manipulation and retrieval of data from a database.  Relational.
CSCD343- Introduction to databases- A. Vaisman1 Relational Algebra.
C++ fundamentals.
Relational Algebra, R. Ramakrishnan and J. Gehrke (with additions by Ch. Eick) 1 Relational Algebra.
® Eurostep.ESUKPC v0.1©Copyright Eurostep Limited An Introduction to ISO STEP Part 25 David Price.
Chapter 1 Database Systems. Good decisions require good information derived from raw facts Data is managed most efficiently when stored in a database.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
© Janice Regan, CMPT 128, Jan CMPT 128 Introduction to Computing Science for Engineering Students Creating a program.
Faculty of Informatics and Information Technologies Slovak University of Technology Peter Kajsa and Ľubomír Majtás Design.
Supporting Automatic Model Inconsistency Fixing Yingfei Xiong University of Tokyo, Japan Zhenjiang HuNational Institute of Informatics, Japan Haiyan ZhaoPeking.
Chapter 9 Integrity. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.9-2 Topics in this Chapter Predicates and Propositions Internal vs.
® IBM Software Group © 2007 IBM Corporation JSP Expression Language
Software Life Cycle Requirements and problem analysis. –What exactly is this system supposed to do? Design –How will the system solve the problem? Coding.
Validated Model Transformation Tihamér Levendovszky Budapest University of Technology and Economics Department of Automation and Applied Informatics Applied.
Selection Control Structures. Simple Program Design, Fourth Edition Chapter 4 2 Objectives In this chapter you will be able to: Elaborate on the uses.
Oracle Data Integrator Procedures, Advanced Workflows.
Beanbag: A Framework for On- Site Synchronization Yingfei Xiong (speaker), University of Tokyo Zhenjiang Hu, National Institute of Informatics / University.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
CS551 - Lecture 8 1 CS551 Modelling with Objects (Chap. 3 of UML) Yugi Lee STB #555 (816)
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Relational Algebra.
Java 5 Part 1 CSE301 University of Sunderland Harry Erwin, PhD.
Controlling Execution Programming Right from the Start with Visual Basic.NET 1/e 8.
Supporting Parallel Updates with Bidirectional Model Transformations Yingfei Xiong and Masato Takeichi University of Tokyo, Japan Song Hui Peking University,
Database Management Systems 1 Raghu Ramakrishnan Relational Algebra Chpt 4 Xin Zhang.
ICS 321 Fall 2011 The Relational Model of Data (i) Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa 8/29/20111Lipyeow.
Today’s Agenda  Reminder: HW #1 Due next class  Quick Review  Input Space Partitioning Software Testing and Maintenance 1.
1 Relational Algebra Chapter 4, Sections 4.1 – 4.2.
Design Model Lecture p6 T120B pavasario sem.
Beanbag: Operation-based Synchronization with Intra-Relation Support Yingfei Xiong Ph.D. Student University of Tokyo.
Chapter 3 Syntax, Errors, and Debugging Fundamentals of Java.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Database Management Systems Chapter 4 Relational Algebra.
CSCD34-Data Management Systems - A. Vaisman1 Relational Algebra.
A Linguistic Approach to Model Synchronization Yingfei Xiong Ph.D., University of Tokyo Advisors: Zhenjiang Hu and Masato Takeichi 1.
CHAPTER 6 LESSON B Creating Custom Forms. Lesson B Objectives  Suppress default system messages  Create alerts and messages to provide system feedback.
Chapter 11: Advanced Inheritance Concepts. Objectives Create and use abstract classes Use dynamic method binding Create arrays of subclass objects Use.
® IBM Software Group © 2007 IBM Corporation Module 3: Creating UML Diagrams Essentials of Modeling with IBM Rational Software Architect, V7.5.
Andrey Karaulov, Alexander Strabykin Institute for System Programming Russian Academy of Sciences SYRCoSE: Spring Young Researchers Colloquium on Software.
Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환.
4 - Conditional Control Structures CHAPTER 4. Introduction A Program is usually not limited to a linear sequence of instructions. In real life, a programme.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 The Relational Model Chapter 3.
Syntax Analysis Or Parsing. A.K.A. Syntax Analysis –Recognize sentences in a language. –Discover the structure of a document/program. –Construct (implicitly.
More SQL: Complex Queries, Triggers, Views, and Schema Modification
CS 326 Programming Languages, Concepts and Implementation
About the Presentations
Relational Algebra Chapter 4, Part A
Introduction to C++ Programming
Beanbag : Support Synchronization in Software Engineering Applications
Towards Automatic Model Synchronization from Model Transformation
Synchronizing Software Engineering Artifacts
Formal Methods in Software Engineering 1
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Presentation transcript:

Beanbag: Facilitating Model Inconsistency Fixing Yingfei Xiong Ph.D. Student Advisor: Zhenjiang Hu and Masato Takeichi University of Tokyo 1

Contents(45mins) Introduction – Running example C1 (try to find a better one) – Beanbag The Beanbag Language – primitives values and updates equality, constant equality, and, or – Structural Values dictionaries dictionary updates forall – control deletion exists – control insertion – Representing Objects How to represent objects using dictionaries get attribute: d.k, let referencing attribute in another object: one Experiment and Implementation Conclusion 2

Motivation Model software system often involves models with complex relations. Equal Dependent 3

Relation Description in OCL C1: context Message inv let rec = self.receiver in let ops = rec.base.operations in ops->exists(oper | oper.name = self.name) C2: context Message inv self.sender <> null and self.receiver <> null 4

Inconsistency Inconsistency will be caused when some part is updated by users choose 5

Automatic Inconsistency Fixing Modern modeling tools propagate updates automatically to fix inconsistency choose 6

Fixing Procedures Current approaches [Grundy94] provide automatic fixing through fixing procedures Fixing procedure: When a type of change occurs Do actions An example When a method in a class diagram is renamed Do find corresponding messages in sequence diagrams rename these messages 7

Problem 1 : High Development Cost Many types of updates may violate a relation Developers have to write code for each type C1: context Message inv let rec = self.receiver in let ops = rec.base.operations in ops->exists(oper | oper.name = self.name) Rename Move Change Type Delete Rename 8

Problem 1 : High Development Cost IBM Rational Software Architect has failed to implement fixing actions for some types of changes C1: context Message inv let rec = self.receiver in let ops = rec.base.operations in ops->exists(oper | oper.name = self.name) Rename Move Change Type Delete Rename 9

Problem 2 : Correctness not Assured It is difficult to verify whether the fixing actions correctly propagate the updates or not When a method in a class diagram is renamed Do find all messages in sequence diagrams rename these messages 10

Idea : Automatic Derivation of Fixing Procedures From simple relations like a=b, fixing procedures can be automatically derived a=2 b=2 3 3 a=2 b=2 3 3 a=2 b=2 3 3 a=2 b=2 3 4 report conflict Idea : derive fixing procedures from consistency relations 11

Problem A consistency relation may correspond to multiple fixing procedures Need developers to tell the system which one to use C1: context Message inv let rec = self.receiver in let ops = rec.base.operations in ops->exists(oper | oper.name = self.name) choose choose() 12

Our Solution : Beanbag A language for writing fixing procedures from consistency relation perspective Attaching fixing semantics to common OCL constructs Providing multiple ways to construct one relation, each representing a different fixing behavior 13

Beanbag Program: An Example context Message inv let rec = self.receiver in let ops = rec.base.operations in ops->exists(oper | oper.name = self.name) def C1(msg, model) = let rec = model.(msg."receiver") in let opRefs = model.(rec."base")."operations" in opRefs->exists(opRef | model.opRef."name"=msg."name") OCL Beanbag 14

Working Process of Beanbag Application Data Fixing Procedure Updates Users Beanbag Program Compile 15

Customize Fixing Behavior def C1(msg, model) = let rec = model.(msg."receiver") in let opRefs = model.(rec."base")."operations" in opRefs->exists!(opRef | model.opRef."name"=msg."name") def C1(msg, model) = let rec = model.(msg."receiver") in let opRefs = model.(rec."base")."operations" in opRefs->exists(opRef | model.opRef."name"=msg."name") rename a message rename an operation rename a message add a new operation 16

Correctness Properties What fixing procedures are correct? – Consistency – Preservation – Stability 17

Consistency After updating, the data should satisfy the consistency relation choose Equal 18

Preservation A fixing procedure cannot overwrite user updates choose select 19

Stability If there is no update, the synchronizer produce no update. 20

Beanbag Language First, let us consider relations on primitive values Primitive values: integers, strings, booleans… Updates on primitive values: – !v: replace the old value with v – void: no update Basic Relation: a = b a:!1 b:void a:!1 b:!1 a:2 b:2 a=b 21

a=v a:!2 a:2 a=2 a:!1 a:2 a=2 failure! 22

Conjunction a:void b:void c:!1 a:void b:void c:!1 a:!1 b:!1 c:!1 a:!1 b:!1 c:!1 a:2 b:2 c:2 a:2 b:2 c:2 a=b and b=c a:void b:void a:2 b:2 a=b b:void c:!1 b:!1 c:!1 b:2 c:2 b=c a:void b:!1 a:!1 b:!1 a:2 b:2 a=b 23

Disjunction a=1 or a=2 Basic idea: use either “a=1” or “a=2” to synchronize Problem: When we change a from 1 to 2, the input value a=1 is not consistent for “a=2” Solution: Require fixing procedures to handle inconsistent input values 24

Handling Inconsistent Values a:!1 b:void a:!1 b:!1 a:2 b:3 a=b a:void b:void a:!3 b:!3 a:2 b:3 a=b a:void a:!2 a:3 a=2 25

Disjunction a=1 or a=2 a:!2 a:1 a=1 a:!2 a:1 failure! a=2 a:!2 a:1 a:!2 26

Customize Fixing Behavior in Disjunction a:!3 b:void c:void a:!3 b:void c:void a:!3 b:!3 c:void a:!3 b:!3 c:void a:5 b:5 c:5 a:5 b:5 c:5 a=b or a=c a:!3 b:void c:void a:!3 b:void c:void a:!3 b:void c:!3 a:!3 b:void c:!3 a:5 b:5 c:5 a:5 b:5 c:5 a=c or a=b 27

Customize Fixing Behavior in Disjunction a:void a:!1 a:5 a=1 or a=2 a:void a:!2 a:5 a=2 or a=1 28

Protecting variables from being changed by fixing procedures a:!1 b:void a:!1 b:!1 a:2 b:3 protect a in a=b protect a in a=b a:void b:!1 a:2 b:3 protect a in a=b protect a in a=b failure! 29

Dictionaries: Structural Values A dictionary maps keys to values – {1->”a”, 2->”b”, 3->”c”} – {“Name”->”UserEJB”, “Persistent”->true} An update on dictionary is also a dictionary mapping from keys to updates {1->”a”, 2->”b”, 3->”c”},4->”y” “x” {1->!”x”, 2->!null, 4->!”y”} 30

Representing Objects {1->{name ->Display, operations->{10->2, 11->3, 12->4, 13->5}}, 2->{name->select, parameters->{}}, 3->{name->stop, parameters->{}}, 4->{name->play, parameters->{}}, 5->{name->draw, parameters->{}}, 31

d.k: getting value from dictionary d:void k:void v:!2 d:void k:void v:!2 d:{a->!2} k:void v:!2 d:{a->!2} k:void v:!2 d:{a->1, b->3} k:a v:1 d:{a->1, b->3} k:a v:1 v=d.k d:void k:!b v:void d:void k:!b v:void d:void k:void v:!3 d:void k:void v:!3 d:{a->1, b->3} k:a v:1 d:{a->1, b->3} k:a v:1 v=d.k d:void k:void v:void d:void k:void v:void d:void k:void v:!1 d:void k:void v:!1 d:{a->1, b->3} k:a v:4 d:{a->1, b->3} k:a v:4 v=d.k What if we want to write (d.k1).k2 or d1.(d2.k)? 32

let let k’=d2.k in v=d1.k’ – v=d1.(d2.k) let d’=d.k1 in v=d’.k2 – v=d.k1.k2 The fixing semantics of “Let” is similar to “and” – let k’=d2.k in v=d1.k’ – k’=d2.k and v=d1.k’ but we must find the value of k’ 33

E : evaluate expressions like OCL E[d.k] = d.k E[v1=v2] = v1==v2 E[expr1 and expr2] = E[expr1] ⋀ E[expr2] E[expr1 or expr2] = E[expr1] ⋁ E[expr2] Let: First evaluate the value of the inner variable, then proceed as “and” 34

The fixing procedure of Let d1:void d2:void k:!2 v:void d1:void d2:void k:!2 v:void d1:void d2:void k:!2 v:!j d1:void d2:void k:!2 v:!j d1:{a->i, b->j} d2:{1->a, 2->b} k:1 v:i d1:{a->i, b->j} d2:{1->a, 2->b} k:1 v:i let k’=d2.k in v=d1.k’ let k’=d2.k in v=d1.k’ k’:void d2:void k:!2 k’:void d2:void k:!2 k’:!b d2:void k:!2 k’:!b d2:void k:!2 k’:E[d2.k]=a d2:{1->a, 2->b} k:1 k’:E[d2.k]=a d2:{1->a, 2->b} k:1 k’=d2.k k’:!2 d1:void v:void k’:!2 d1:void v:void k’:!2 d1:void v:!j k’:!2 d1:void v:!j k’:E[d2.k]=a d1:{a->i, b->j} v:i k’:E[d2.k]=a d1:{a->i, b->j} v:i v=d1.k’ 35

exists d->exits(v | v=v0) E[d->exits(v | v=v0)]= ∃ k ∊ dom(d). E[d.k=v0] Fixing Procedure – add a new item if E[d->exits(v | v=v0)]=false – the key of the new item is uniquely generated – the value of the new item is initially null 36

exists d:void v0:!c d:{3->!c} v:!c d:{3->!c} v:!c d:{1->a, 2->b} v0:a d->exits (v | v=v0) d->exits (v | v=v0) v:void v0:!c v:!c v0:!c v:!c v0:!c v:null v0:a v=v0 37

exists! d->exits!(v | v=v0) E[d->exits!(v | v=v0)]= E[d->exits(v | v=v0)] Fixing Procedure – find the entry that satisfies v=v0 from the input values – use the fixing procedure of v=v0 to fix inconsistency 38

exists! d:void v0:!c d:{1->!c} v:!c d:{1->!c} v:!c d:{1->a, 2->b} v0:a d->exits! (v | v=v0) d->exits! (v | v=v0) v:void v0:!c v:!c v0:!c v:!c v0:!c v:a v0:a v=v0 39

forall d->forall(v | v.”isClass”=true and v.”name”=a) E[d->forall(v | expr)]= ∀ k ∊ dom(d). E[expr] Fixing Procedure – call the fixing procedure of the inner relation on every entry 40

Customize fixing behavior in forall d->forall(v | v.”isClass”=true and v.”name”=a) d->forall(v | protect v in (v.”isClass”=true and v.”name”=a) or v=null) d->forall(v | protect v in (v.”isClass”=true and v.”name”=a) or v.”isClass”=false) a changes rename all classes in d a changes delete all classes in d a changes change all classes to non-classes in d change all classes to non-classes in d 41

Review: Beanbag Program for C1 def C1(msg, model) = let rec = model.(msg."receiver") in let opRefs = model.(rec."base")."operations" in opRefs->exists(opRef | model.opRef."name"=msg."name") 42

Summary: Constructs in Beanbag v1=v2 v=const expr1 and expr2 expr1 or expr2 d.k let v=expr in expr d->forall(v | expr) d->exists(v | expr) 43

Summary: Fixing Behavior Customization ConstructsCustomization v1=v2 v2=v1 expr1 and expr2 expr2 and expr1 expr1 or expr2 expr2 or expr1 d->exists(v | expr)d->exists(v | expr) d->exists!(v | expr) 44

Evaluating Expressiveness We collected 84 consistency relations from MOF standard, UML standard, and industry [Egyed07] From these relations, we identified requirements for 24 fixing procedures We implemented 17 programs, 71% of all programs The rest 7 programs can be implemented with minor extensions to Beanbag 45

Conclusion Inconsistency fixing can be approached by a language – attaching fixing actions to primitive relations – gluing primitive relations by combinators The language is correct according to three properties The language is expressive as it can express many useful fixing behaviors in practice 46