Using Graph Rewriting Models for Object-Oriented Oriented Software Evolution
|
|
- Charlotte Hill
- 5 years ago
- Views:
Transcription
1 Using Graph Rewriting Models for Object-Oriented Oriented Software volution om Mens rogramming echnology ab epartment of Computer Science Vrije Universiteit Brussel
2 Object-oriented software evolution Need better tool support for version control e.g. upgrading application frameworks collaborative software development e.g. software merging evolution at a higher level of abstraction e.g. refactoring e.g. evolution of design pattern (instances) change propagation, change impact analysis, effort estimation... Seminaire CRI, 8/3/2002 UC 2
3 ool support must be scalable applicable to large-scale industrial software systems generic major challenge for the research community is to develop a good theoretical understanding an underpinning for maintenance and evolution, which scales to industrial applications. [Bennett&Rajlich 2000] independent of the programming or modelling language applicable in all phases of the software life-cycle formally founded to prove that results are well-formed, correct, complete, confluent, compositional,... Seminaire CRI, 8/3/2002 UC 3
4 Graph rewriting can be used as formal model for software evolution graphs compact and expressive representation of program structure and behaviour 2- nature removes redundancy in source code (e.g., localised naming) graph rewriting intuitive description of transformation of complex graph-like structures theoretical results help in the analysis of such structures confluence property, parallel/sequential independence, critical pair analysis, compositionality, Seminaire CRI, 8/3/2002 UC 4
5 wo applications Software refactoring use graph rewriting to express and detect various kinds of behaviour preservation in collaboration with rof. Serge emeyer and rof. irk Janssens, University of ntwerp Software merging use graph rewriting to detect evolution/merge conflicts between parallel evolutions of the same software h thesis of om Mens Seminaire CRI, 8/3/2002 UC 5
6 pplication 1 Software Refactoring
7 What is refactoring? Refactorings are software transformations that restructure an object-oriented application while preserving its behaviour. ccording to Fowler (1999), refactoring improves the design of software makes software easier to understand helps you find bugs helps you program faster Formalisms can help to gain insight in the fundamental underlying principles prove correctness, e.g., to guarantee behaviour preservation Seminaire CRI, 8/3/2002 UC 7
8 Refactoring case study: N Goal: show feasibility of graph rewriting formalism to express and detect various kinds of behaviour preservation 1. originate(p) workstation 1 3. accept(p) workstation 3 2. send(p) fileserver 1 8.print(p) printer 1 7. accept(p) workstation 2 6. send(p) 5. accept(p) 4. send(p) Seminaire CRI, 8/3/2002 UC 8
9 UM class diagram Node originator acket nextnode name accept(p:acket) send(p:acket) addressee contents Workstation originate(p:acket) rintserver print(p:acket) FileServer save(p:acket) Seminaire CRI, 8/3/2002 UC 9
10 Java source code public class Node { public String name; public Node nextnode; public void accept(acket p) { this.send(p); } protected void send(acket p) { System.out.println( name + "sends to" + nextnode.name); nextnode.accept(p); } } public class rintserver extends Node { public void print(acket p) { System.out.println(p.contents); } public void accept(acket p) { if(p.addressee == this) this.print(p); else super.accept(p); } } Seminaire CRI, 8/3/2002 UC } public class acket { public String contents; public Node originator; public Node addressee; } public class Workstation extends Node { public void originate(acket p) { p.originator = this; this.send(p); } public void accept(acket p) { if(p.originator == this) System.err.println("no destination"); else super.accept(p); } 10
11 Refactoring xample 1: ncapsulate Field Fowler 1999, page 206 here is a public field Make it private and provide accessors public class Node { public String name; public Node nextnode; public void accept(acket p) { this.send(p); } protected void send(acket p) { System.out.println( name + "sends to" + nextnode.name); nextnode.accept(p); } } Seminaire CRI, 8/3/2002 UC om Mens, Vrije Universiteit } Brussel public class Node { private String name; private Node nextnode; public String getname() { return this.name; } public void setname(string s) { this.name = s; } public Node getnextnode() { return this.nextnode; } public void setnextnode(node n) { this.nextnode = n; } public void accept(acket p) { this.send(p); } protected void send(acket p) { System.out.println( this.getname() + "sends to" + this.getnextnode().getname()); this.getnextnode().accept(p); } 11
12 Refactoring xample 2: xtract Method Fowler 1999, page 110 You have a code fragment that can be grouped together urn the fragment into a method whose name explains the purpose of the method public class Node {... public void accept(acket p) { this.send(p); } protected void send(acket p) { System.out.println( this.getname() + "sends to" + this.getnextnode().getname()); this.getnextnode().accept(p); } } public class Node {... public void accept(acket p) { this.send(p); } protected void send(acket p) { this.log(p); this.getnextnode().accept(p); } protected void log(acket p) { System.out.println( this.getname() + "sends to" + this.getnextnode().getname()); } Seminaire CRI, 8/3/2002 UC } 12
13 Graph representation part 1 program structure acket C println M (s) String C contents originator addressee send M (p) I Node C I accept M (p) name nextnode (send) B (accept) B originate M (p) Workstation C rintserver C print M (p) (originate) B (accept) B (accept) B (print) B Seminaire CRI, 8/3/2002 UC 13
14 Graph representation part 2 program behaviour for class Node Node C void send(acket p) { 1: System.out.println( name + "sends to" + nextnode.name); 2: nextnode.accept(p); } name nextnode (send) B (accept) B M println M (s) send M (p) accept M (p) Seminaire CRI, 8/3/2002 UC 15
15 Refactoring xample 1: ncapsulate Field before the refactoring Node C name nextnode (send) B (accept) B M println M (s) send M (p) accept M (p) Seminaire CRI, 8/3/2002 UC 18
16 Refactoring xample 1: ncapsulate Field after the refactoring 1 Node C nextnode name 1 (getname) B (getnextnode) B (send) B (accept) B 2 1 String C 1 getname M getnextnode M + M println M send M accept M (s) (p) (p) Seminaire CRI, 8/3/2002 UC 19
17 Refactoring xample 1: ncapsulatefield graph production refactoring achieved by applying 2 occurrences of production ncapsulatefield(class,attr,type,accessor,updater) ncapsulatefield(node,name,string,getname,setname) ncapsulatefield(node,nextnode,node,getnextnode,setnextnode) (updater) B type C (accessor) B 1 6 class C attr U (updater) B type C 1 1 attr U 3 class C 1 2 (accessor) B updater M accessor M 4 updater M 5 accessor M (p) (p) Seminaire CRI, 8/3/2002 UC 20
18 Refactoring xample 1: Behaviour preservation ncapsulatefield preserves behaviour access preserving: all attribute nodes can still be accessed via a transitive closure attr accessor M B attr update preserving: all attribute nodes can still be updated via a transitive closure U attr U updater M B attr Seminaire CRI, 8/3/2002 UC 21
19 Refactoring xample 2: xtract Method before the refactoring xtractmethod(node,send,log,{1}) Node C name nextnode (send) B M println M send M accept M (s) (p) (p) Seminaire CRI, 8/3/2002 UC 22
20 Refactoring xample 2: xtract Method after the refactoring xtractmethod(node,send,log,{1}) Node C name nextnode (log) B (send) B M println M log M send M accept M (s) (p) (p) (p) Seminaire CRI, 8/3/2002 UC 23
21 Refactoring xample 2: xtractmethod graph production refactoring is achieved by applying an occurrence of production xtractmethod(class,old,new,statist) given the body of method old in class, redirect all statements in Statist to the body of a parameterless method new class C class C (new) B new M α 3 (old) B (new) B α (old) B α Statist old M new M old M 1 1 (method parameters can be introduced afterwards by ddarameter) Seminaire CRI, 8/3/2002 UC 24
22 Refactoring xample 2: Behaviour preservation xtractmethod preserves behaviour statement preserving: all expressions (calls, accesses, updates) that were performed before the refactoring, are still performed (via transitive closure) after the refactoring old M B a old M B 2 new M B a 3 α Statist Seminaire CRI, 8/3/2002 UC 25
23 Behaviour preservation types ccess preservation (see ncapsulatefield) each method body (indirectly) performs at least the same attribute accesses as it did before the refactoring Update preservation (see ncapsulatefield) each method body (indirectly) performs at least the same attribute updates as it did before the refactoring Statement preservation (see xtractmethod) each method body (indirectly) performs at least the same statements as Call preservation each method body (indirectly) performs at least the same method calls as ype preservation each statement in each method body still has the same result type or return type as Seminaire CRI, 8/3/2002 UC 26
24 Refactoring: Conclusion Graph rewriting seems a useful and promising formalism to provide support for refactoring More practical validation needed Current experiment only focuses on behaviour preservation formalism can assist the refactoring process in many other ways roposed FWO research project (4 years / 3 persons) Seminaire CRI, 8/3/2002 UC 27
25 Refactoring: Open questions Which program properties should be preserved by refactorings? input/output behaviour, timing constraints, static versus dynamic behaviour support for non-behaviour-preserving refactorings? What is the complexity of a refactoring? complexity of applicability / complexity of applying the refactoring How do refactorings affect quality factors? increase/decrease complexity, understandability, maintainability, How can refactorings be composed/decomposed? composite refactorings / extracting refactorings from successive releases How do refactorings interact? parallel application of refactorings may lead to consistency problems How do refactorings affect design models? anguage-independent formalism for refactoring? Seminaire CRI, 8/3/2002 UC 28
26 pplication 2 Software Merging
27 What is Software Merging? Context: Collaborative Software evelopment many software developers working together on the same software need to integrate parallel changes made to the same code Software merging automated tool support for integrating these parallel changes detect inconsistencies (conflicts) between parallel changes provide support for resolving these inconsistencies Merge tools are usually part of a configuration management system or version management system e.g. CVS, RCS, ClearCase, dele,... Seminaire CRI, 8/3/2002 UC 30
28 roblem public class Node { public String name; public Node nextnode; public void accept(acket p) { this.send(p); } protected void send(acket p) { System.out.println( name + "sends to" + nextnode.name); nextnode.accept(p); } } xtract Method public class Node {... public void accept(acket p) { this.send(p); } protected void send(acket p) { this.log(p); this.nextnode().accept(p); } protected void log(acket p) { System.out.println( name + "sends to" + nextnode.name); } } ncapsulate Field public class Node { private String name; private Node nextnode; public String getname() {return this.name;} public void setname(string s) {this.name=s;} public Node getnextnode() { return this.nextnode; } public void setnextnode(node n) { this.nextnode = n; } public void accept(acket p) {this.send(p);} protected void send(acket p) { System.out.println(this.getName() + "send to" + this.getnextnode().getname()); this.getnextnode().accept(p); } } Current merge tools cannot merge the two parallel changes automatically due to a merge conflict in the send method Seminaire CRI, 8/3/2002 UC 31
29 Solution Node C Node C name nextnode (send) B (accept) B name nextnode (log) B (send) B (accept) B 1 send M 2 (p) accept M ncapsulate Field (p) log M 1 send M 1 2 (p) accept M xtract Method 1 Node C nextnode name 1 (getname) B (getnextnode) B (send) B (accept) B 1 getname M getnextnode M send M 2 (p) accept M Sequential application of the parallel graph rewritings yields correct merge result Seminaire CRI, 8/3/2002 UC 32
30 Solution xpress and document software evolution by means of explicit graph transformations etect whether parallel evolutions can be sequentialised (parallel/sequential independence) If not, syntactic conflicts need to be resolved first e.g. renaming same entity twice If yes, merging corresponds to sequential application of graph transformations Order of application is irrelevant (confluence property) otential semantic conflicts need to be detected (based on category-theoretical notion of pushouts/pullbacks) Seminaire CRI, 8/3/2002 UC 33
31 For more details see formal foundation for object-oriented software evolution om Mens. h hesis, Vrije Universiteit Brussel, September 1999 xtended abstract in roc. Int. Conf. Software Maintenance 2001, pp , I Computer Society ress Conditional graph rewriting as a domain-independent formalism for software evolution om Mens. roc. gtive 99, ecture Notes in Computer Science 1779: , Springer-Verlag, 2000 state-of-the-art survey on software merging om Mens. I rans. Software ngineering, 28(5), May 2002 Seminaire CRI, 8/3/2002 UC 34
32 Open Issue: Structural Conflicts Shape Shape Square Rectangle Circle InsertClass (Shape,Quadrangle, [Square,Rectangle]) Quadrangle Circle ddsubclass(shape,arallellogram) ddsubclass(shape,riangle) Square Rectangle Shape More difficult to detect in a general way arallellogram riangle Square Rectangle Circle Seminaire CRI, 8/3/2002 UC 35
33 General Conclusion Graph rewriting can be used as a formal model for various aspects of software evolution software refactoring software merging Formalism allows us to express interesting properties Behaviour preservation of refactorings Compositionality of refactorings Syntactic and semantic merge conflicts More theoretical research and practical validation needed roposed FWO research project (4 years / 3 persons) pply formalism on evolution of real software systems Seminaire CRI, 8/3/2002 UC 46
Formal tool support for software evolution
Service de Génie Logiciel Formal tool support for software evolution Tom Mens staff.umh.ac.be/mens.tom/ www.umh.ac.be/~genlog Université de Mons-Hainaut Problem statement More and better tool support needed
More informationDetecting Structural Refactoring Conflicts Using Critical Pair Analysis
SETra 2004 Preliminary Version Detecting Structural Refactoring Conflicts Using Critical Pair Analysis Tom Mens 1 Software Engineering Lab Université de Mons-Hainaut B-7000 Mons, Belgium Gabriele Taentzer
More information2nd Belgian-Dutch workshop on Software Evolution
2nd Belgian-Dutch workshop on Software Evolution BENEVOL 2004 8-9 July 2004 University of Antwerp Belgium Problem statement More and better tool support needed for software evolution traceability management
More informationFormal Support for Model Evolution
Formal Support for Model Evolution Tom Mens http://w3.umh.ac.be/genlog Software Engineering Lab University of Mons-Hainaut Belgium Introduction - Model Evolution More and better tool support needed for
More informationRefactoring-aware Configuration Management for Object-Oriented Programs
Refactoring-aware Configuration Management for Object-Oriented Programs Danny Dig, Kashif Manzoor, Ralph Johnson University of Illinois at Urbana-Champaign {dig, manzoor2, rjohnson@uiuc.edu Tien N. Nguyen
More informationOn Meaning Preservation of a Calculus of Records
On Meaning Preservation of a Calculus of Records Emily Christiansen and Elena Machkasova Computer Science Discipline University of Minnesota, Morris Morris, MN 56267 chri1101, elenam@morris.umn.edu Abstract
More informationCoping with API Evolution for Running, Mission-Critical Applications Using Virtual Execution Environment
Coping with API Evolution for Running, Mission-Critical Applications Using Virtual Execution Environment Bashar Gharaibeh, Tien N. Nguyen, and J. Morris Chang Electrical and Computer Engineering Department
More informationA Formal Resolution Strategy for Operation-Based Conflicts in Model Versioning Using Graph Modifications
A Formal Resolution Strategy for Operation-Based Conflicts in Model Versioning Using Graph Modifications Hartmut Ehrig 1, Claudia Ermel 1 and Gabriele Taentzer 2 1 Technische Universität Berlin, Germany
More informationFormalizing Software Refactoring in the Distributed Environment by aednlc Graph Grammar
Formalizing Software Refactoring in the Distributed Environment by aednlc Graph Grammar Leszek Kotulski, Adrian Nowak Institute of Computer Science, Jagiellonian University Nawojki 11, 30-072 Kraków, Poland
More informationDetecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis
Detecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis Tom Mens 1, Ragnhild Van Der Straeten 2, and Maja D Hondt 3 1 Software Engineering Lab, Université de Mons-Hainaut
More informationTowards semantic merging of versions of BDI agent systems
Towards semantic merging of versions of BDI agent systems Yingzhi Gou, Hoa Khanh Dam and Aditya Ghose School of Computer Science and Software Engineering University of Wollongong New South Wales 2522,
More informationChapter 2 The Language PCF
Chapter 2 The Language PCF We will illustrate the various styles of semantics of programming languages with an example: the language PCF Programming language for computable functions, also called Mini-ML.
More information9 Refactoring. Refactoring changes the software structure but does not change the functionality of the program. important activity during evolution
9 Refactoring Refactoring changes the software structure but does not change the functionality of the program important activity during evolution Refactoring consists of behaviour preserving transformations
More informationChapter 7. Modular Refactoring. 7.1 Introduction to Modular Refactoring
Chapter 7 Modular Refactoring I n this chapter, the role of Unified Modeling Language (UML) diagrams and Object Constraint Language (OCL) expressions in modular refactoring have been explained. It has
More informationCmSc 150 Fundamentals of Computing I. Lesson 28: Introduction to Classes and Objects in Java. 1. Classes and Objects
CmSc 150 Fundamentals of Computing I Lesson 28: Introduction to Classes and Objects in Java 1. Classes and Objects True object-oriented programming is based on defining classes that represent objects with
More informationAutomating Big Refactorings for Componentization and the Move to SOA
Automating Big Refactorings for Componentization and the Move to SOA IBM Programming Languages and Development Environments Seminar 2008 Aharon Abadi, Ran Ettinger and Yishai Feldman Software Asset Management
More informationThe Java Memory Model
Jeremy Manson 1, William Pugh 1, and Sarita Adve 2 1 University of Maryland 2 University of Illinois at Urbana-Champaign Presented by John Fisher-Ogden November 22, 2005 Outline Introduction Sequential
More informationMaking Program Refactoring Safer
Making Program Refactoring Safer Gustavo Soares 1, Rohit Gheyi 1, Dalton Serey 1 1 Department of Computing and Systems UFCG 58429-900 Campina Grande PB Brazil {gsoares,rohit,dalton}@dsc.ufcg.edu.br Abstract.
More information1 Version management tools as a basis for integrating Product Derivation and Software Product Families
1 Version management tools as a basis for integrating Product Derivation and Software Product Families Jilles van Gurp, Christian Prehofer Nokia Research Center, Software and Application Technology Lab
More informationProcess Model Consistency Measurement
IOSR Journal of Computer Engineering (IOSRJCE) ISSN: 2278-0661, ISBN: 2278-8727Volume 7, Issue 6 (Nov. - Dec. 2012), PP 40-44 Process Model Consistency Measurement Sukanth Sistla CSE Department, JNTUniversity,
More informationInternational Journal of Scientific & Engineering Research, Volume 8, Issue 2, February ISSN
International Journal of Scientific & Engineering Research, Volume 8, Issue 2, February-2017 164 DETECTION OF SOFTWARE REFACTORABILITY THROUGH SOFTWARE CLONES WITH DIFFRENT ALGORITHMS Ritika Rani 1,Pooja
More informationRefactoring. Section (JIA s) OTHER SOURCES
Refactoring Section 7.2.1 (JIA s) OTHER SOURCES Code Evolution Programs evolve and code is NOT STATIC Code duplication Outdated knowledge (now you know more) Rethink earlier decisions and rework portions
More informationMotivation: Model-driven. driven Engineering. Semantics of Model Transformation. Reiko Heckel University of Leicester, UK
Semantics of Model Transformation Reiko Heckel University of Leicester, UK, University of Birmingham, 1 March 2007 Motivation: Model-driven driven Engineering Focus and primary artifacts are models instead
More informationCS 242. Fundamentals. Reading: See last slide
CS 242 Fundamentals Reading: See last slide Syntax and Semantics of Programs Syntax The symbols used to write a program Semantics The actions that occur when a program is executed Programming language
More informationFINE-GRAIN TRANSFORMATIONS FOR REFACTORING EMMAD I. M. SAADEH THESIS
FINE-GRAIN TRANSFORMATIONS FOR REFACTORING By EMMAD I. M. SAADEH THESIS Submitted in partial fulfillment of the requirements for the degree of Philosophiae Doctor (Computer Science) in the Faculty of Engineering,
More informationA Taxonomy of Model Transformation
Electronic Notes in Theoretical Computer Science 152 (2006) 125 142 www.elsevier.com/locate/entcs A Taxonomy of Model Transformation Tom Mens 1 Software Engineering Lab Université de Mons-Hainaut Mons,
More informationInductively Generated Pointcuts to Support Refactoring to Aspects
Inductively Generated Pointcuts to Support Refactoring to Aspects Tom Tourwé Centrum voor Wiskunde en Informatica P.O. Box 94079, NL-1090 GB Amsterdam The Netherlands Email: tom.tourwe@cwi.nl Andy Kellens
More informationA case in Multiparadigm Programming : User Interfaces by means of Declarative Meta Programming
A case in Multiparadigm Programming : User Interfaces by means of Declarative Meta Programming S. Goderis W. De Meuter J. Brichau Programming Technology Lab, Vrije Universiteit Brussel, Belgium Abstract.
More informationDefining Classes and Methods
Defining Classes and Methods Chapter 4 Chapter 4 1 Basic Terminology Objects can represent almost anything. A class defines a kind of object. It specifies the kinds of data an object of the class can have.
More informationLecture 36: Cloning. Last time: Today: 1. Object 2. Polymorphism and abstract methods 3. Upcasting / downcasting
Lecture 36: Cloning Last time: 1. Object 2. Polymorphism and abstract methods 3. Upcasting / downcasting Today: 1. Project #7 assigned 2. equals reconsidered 3. Copying and cloning 4. Composition 11/27/2006
More informationCOURSE 11 DESIGN PATTERNS
COURSE 11 DESIGN PATTERNS PREVIOUS COURSE J2EE Design Patterns CURRENT COURSE Refactoring Way refactoring Some refactoring examples SOFTWARE EVOLUTION Problem: You need to modify existing code extend/adapt/correct/
More informationModelling Software Evolution using Algebraic Graph Rewriting
Modelling Software Evolution using lgebraic Graph Rewriting Selim iraci and Pim van den roek Software Engineering Group aculty of Electrical Engineering, Mathematics and omputer Science University of Twente
More informationCompositional Model Based Software Development
Compositional Model Based Software Development Prof. Dr. Bernhard Rumpe http://www.se-rwth.de/ Seite 2 Our Working Groups and Topics Automotive / Robotics Autonomous driving Functional architecture Variability
More informationXRay Views: Understanding the Internals of Classes
XRay Views: Understanding the Internals of Classes Gabriela Arévalo, Stéphane Ducasse, Oscar Nierstrasz Software Composition Group University of Bern (Switzerland) {arevalo, ducasse, oscar}@iam.unibe.ch
More informationBoolean Representations and Combinatorial Equivalence
Chapter 2 Boolean Representations and Combinatorial Equivalence This chapter introduces different representations of Boolean functions. It then discusses the applications of these representations for proving
More information5. Introduction to the Lambda Calculus. Oscar Nierstrasz
5. Introduction to the Lambda Calculus Oscar Nierstrasz Roadmap > What is Computability? Church s Thesis > Lambda Calculus operational semantics > The Church-Rosser Property > Modelling basic programming
More informationOn the Correctness of Model Transformations. Matthew Nizol CSE 814, Fall 2014 Thursday, December 11, 2014
On the Correctness of Model Transformations Matthew Nizol CSE 814, Fall 2014 Thursday, December 11, 2014 Agenda Context: Model-driven development Background on verification techniques Presentation of each
More informationReuse Contracts As Component Interface. Descriptions. Koen De Hondt, Carine Lucas, and Patrick Steyaert. Programming Technology Lab
Reuse Contracts As Component Interface Descriptions Koen De Hondt, Carine Lucas, and Patrick Steyaert Programming Technology Lab Computer Science Department Vrije Universiteit Brussel Pleinlaan 2, B-1050
More informationMore About Classes CS 1025 Computer Science Fundamentals I Stephen M. Watt University of Western Ontario
More About Classes CS 1025 Computer Science Fundamentals I Stephen M. Watt University of Western Ontario The Story So Far... Classes as collections of fields and methods. Methods can access fields, and
More informationBottom-Up Parsing. Lecture 11-12
Bottom-Up Parsing Lecture 11-12 (From slides by G. Necula & R. Bodik) 9/22/06 Prof. Hilfinger CS164 Lecture 11 1 Bottom-Up Parsing Bottom-up parsing is more general than topdown parsing And just as efficient
More informationModel refactoring within a Sequencer TOMAŽ KOS 1, TOMAŽ KOSAR 2, JURE KNEZ 1, MARJAN MERNIK 2
Model refactoring within a Sequencer TOMAŽ KOS 1, TOMAŽ KOSAR 2, JURE KNEZ 1, MARJAN MERNIK 2 1 DEWESoft d.o.o. Gabersko 11a, 1420 Trbovlje SLOVENIA {tomaz.kos, jure.knez}@dewesoft.si http://www.dewesoft.si
More informationIntro to: Design Principles
Intro to: Design Principles Pragmatic Programmer: Eliminate Effects Between Unrelated Things design components that are: self-contained, independent, and have a single, well-defined purpose Software Design
More informationA CALCULUS WITH LAZY MODULE OPERATORS
A CALCULUS WITH LAZY MODULE OPERATORS Davide Ancona, Sonia Fagorzi and Elena Zucca DISI - Università di Genova Via Dodecaneso, 35, 16146 Genova (Italy)* {davide,fagorzi,zucca}@disi.unige.it Abstract Modern
More informationRecitation 02/02/07 Defining Classes and Methods. Chapter 4
Recitation 02/02/07 Defining Classes and Methods 1 Miscellany Project 2 due last night Exam 1 (Ch 1-4) Thursday, Feb. 8, 8:30-9:30pm PHYS 112 Sample Exam posted Project 3 due Feb. 15 10:00pm check newsgroup!
More informationObject-Oriented Theories for Model Driven Architecture
Object-Oriented Theories for Model Driven Architecture Tony Clark 1, Andy Evans 2, Robert France 3 1 King s College London, UK, anclark@dcs.kcl.ac.uk, 2 University of York, UK, andye@cs.york.ac.uk, 3 University
More information20 Years of. Improve the Design of your Code. Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015
20 Years of Design Patterns Improve the Design of your Code Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015 Dr Dimitris Dranidis Senior Lecturer in Computer Science Department Programme director
More informationUnderstading Refactorings
Understading Refactorings Ricardo Terra terra@dcc.ufmg.br Marco Túlio Valente mtov@dcc.ufmg.br UFMG, 2010 UFMG, 2010 Understanding Refactorings 1 / 36 Agenda 1 Overview 2 Refactoring 3 Final Considerations
More informationRefactoring Practice: How it is and How it Should be Supported
Refactoring Practice: How it is and How it Should be Supported Zhenchang Xing and EleniStroulia Presented by: Sultan Almaghthawi 1 Outline Main Idea Related Works/Literature Alignment Overview of the Case
More informationBeyond the Refactoring Browser: Advanced Tool Support for Software Refactoring
Beyond the Refactoring Browser: Advanced Tool Support for Software Refactoring Tom Mens Tom Tourwé Francisca Muñoz Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2, 1050 Brussel, Belgium
More informationOntology Merging: on the confluence between theoretical and pragmatic approaches
Ontology Merging: on the confluence between theoretical and pragmatic approaches Raphael Cóbe, Renata Wassermann, Fabio Kon 1 Department of Computer Science University of São Paulo (IME-USP) {rmcobe,renata,fabio.kon}@ime.usp.br
More informationCREATED BY: Muhammad Bilal Arslan Ahmad Shaad. JAVA Chapter No 5. Instructor: Muhammad Naveed
CREATED BY: Muhammad Bilal Arslan Ahmad Shaad JAVA Chapter No 5 Instructor: Muhammad Naveed Muhammad Bilal Arslan Ahmad Shaad Chapter No 5 Object Oriented Programming Q: Explain subclass and inheritance?
More informationLecture 6. Abstract Interpretation
Lecture 6. Abstract Interpretation Wei Le 2014.10 Outline Motivation History What it is: an intuitive understanding An example Steps of abstract interpretation Galois connection Narrowing and Widening
More information1: Introduction to Object (1)
1: Introduction to Object (1) 김동원 2003.01.20 Overview (1) The progress of abstraction Smalltalk Class & Object Interface The hidden implementation Reusing the implementation Inheritance: Reusing the interface
More informationSHIFTLEFT OCULAR THE CODE PROPERTY GRAPH
SHIFTLEFT OCULAR INTRODUCTION ShiftLeft Ocular offers code auditors the full range of capabilities of ShiftLeft s best-in-class static code analysis 1, ShiftLeft Inspect. Ocular enables code auditors to
More informationAdding a Module System to Java
Adding a Module System to Java Rok Strniša Computer Laboratory, University of Cambridge Email: Rok.Strnisa@cl.cam.ac.uk URL: http://www.cl.cam.ac.uk/~rs456/ May 8, 2008 @ The British Computer Society Joint
More informationAPCS Semester #1 Final Exam Practice Problems
Name: Date: Per: AP Computer Science, Mr. Ferraro APCS Semester #1 Final Exam Practice Problems The problems here are to get you thinking about topics we ve visited thus far in preparation for the semester
More informationA Category-Theoretic Approach to Syntactic Software Merging
A Category-Theoretic Approach to Syntactic Software Merging Nan Niu, Steve Easterbrook, and Mehrdad Sabetzadeh Department of Computer Science University of Toronto, Canada Email: {nn, sme, mehrdad}@cs.toronto.edu
More informationHello, world! 206 TUGboat, Volume 31 (2010), No. 2. resulting in: Drawing structured diagrams with SDDL Mathieu Bourgeois and Roger Villemaire
206 TUGboat, Volume 31 (2010), No. 2 Abstract We present SDDL, a Structured Diagram Description Language aimed at producing graphical representations for discrete mathematics and computer science. SDDL
More informationChapter 4 Defining Classes I
Chapter 4 Defining Classes I This chapter introduces the idea that students can create their own classes and therefore their own objects. Introduced is the idea of methods and instance variables as the
More informationInheritance Metrics: What do they Measure?
Inheritance Metrics: What do they Measure? G. Sri Krishna and Rushikesh K. Joshi Department of Computer Science and Engineering Indian Institute of Technology Bombay Mumbai, 400 076, India Email:{srikrishna,rkj}@cse.iitb.ac.in
More informationProgramming Lecture 3
Programming Lecture 3 Expressions (Chapter 3) Primitive types Aside: Context Free Grammars Constants, variables Identifiers Variable declarations Arithmetic expressions Operator precedence Assignment statements
More informationChapter 5: Procedural abstraction. Function procedures. Function procedures. Proper procedures and function procedures
Chapter 5: Procedural abstraction Proper procedures and function procedures Abstraction in programming enables distinction: What a program unit does How a program unit works This enables separation of
More informationUC Irvine UC Irvine Previously Published Works
UC Irvine UC Irvine Previously Published Works Title Differencing and merging within an evolving product line architecture Permalink https://escholarship.org/uc/item/0k73r951 Authors Chen, Ping H Critchlow,
More informationJoint Entity Resolution
Joint Entity Resolution Steven Euijong Whang, Hector Garcia-Molina Computer Science Department, Stanford University 353 Serra Mall, Stanford, CA 94305, USA {swhang, hector}@cs.stanford.edu No Institute
More informationHow to Compute Halting
2015-1-2 0 How to Compute Halting Eric C.R. Hehner Department of Computer Science, University of Toronto hehner@cs.utoronto.ca Abstract: A consistently specified halting function may be computed. Halting
More informationDay 2. COMP 1006/1406A Summer M. Jason Hinek Carleton University
Day 2 COMP 1006/1406A Summer 2016 M. Jason Hinek Carleton University today s agenda a quick look back (Monday s class) assignments a1 is due on Monday a2 will be available on Monday and is due the following
More informationRule Formats for Nominal Modal Transition Systems
Rule Formats for Nominal Modal Transition Systems Anke Stüber Universitet Uppsala, Uppsala, Sweden anke.stuber@it.uu.se Abstract. Modal transition systems are specification languages that allow the expression
More informationForschungsberichte der Fakultät IV Elektrotechnik und Informatik
Forschungsberichte der Fakultät IV Elektrotechnik und Informatik A Formal Resolution Strategy for Operation-Based Conicts in Model Versioning Using Graph Modications Hartmut Ehrig 1 Claudia Ermel 1 Gabriele
More informationIssues on Decentralized Consistency Checking of Multi-lateral Collaborations
Issues on Decentralized Consistency Checking of Multi-lateral Collaborations Andreas Wombacher University of Twente Enschede The Netherlands a.wombacher@utwente.nl Abstract Decentralized consistency checking
More informationCONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS522 Programming Language Semantics
CONVENTIONAL EXECUTABLE SEMANTICS Grigore Rosu CS522 Programming Language Semantics Conventional Semantic Approaches A language designer should understand the existing design approaches, techniques and
More informationRefactoring via Database Representation
6 th International Conference on Applied Informatics Eger, Hungary, January 27 31, 2004. Refactoring via Database Representation Péter Diviánszky 1, Rozália Szabó-Nacsa 2, Zoltán Horváth 1 1 Department
More informationCONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Semantics
CONVENTIONAL EXECUTABLE SEMANTICS Grigore Rosu CS422 Programming Language Semantics Conventional Semantic Approaches A language designer should understand the existing design approaches, techniques and
More informationInterface Automata and Actif Actors
Interface Automata and Actif Actors H. John Reekie Dept. of Electrical Engineering and Computer Science University of California at Berkeley johnr@eecs.berkeley.edu Abstract This technical note uses the
More informationANALYZING PROCESS MODELS USING GRAPH REDUCTION TECHNIQUES
NLYZING PROCESS MODELS USING GRPH REDUCTION TECHNIQUES WSIM SDIQ ND MRI E. ORLOWSK Distributed Systems Technology Centre Department of Computer Science & Electrical Engineering The University of Queensland,
More informationGraph-Transformation Based Support for Model Evolution
Graph-Transformation Based Support for Model Evolution Tom Mens 1 Software Engineering Lab, Université de Mons-Hainaut Av. du champ de Mars 6, 7000 Mons, Belgium tom.mens@umh.ac.be Abstract. During model-driven
More informationRefactoring Aspect Oriented Software
Refactoring Aspect Oriented Software Jochem Rutgers rutgers@ewi.utwente.nl ABSTRACT Existing refactoring methods are able to rewrite object-oriented code to better object-oriented code or to aspect-oriented
More informationAutomatically Generating Refactorings to Suppport API Evolution
Automatically Generating Refactorings to Suppport API Evolution MIT CSAIL Page 1 Outline Library evolution Libraries evolve Clients often don t track library changes Contributions Mechanism to automatically
More informationOperational Semantics 1 / 13
Operational Semantics 1 / 13 Outline What is semantics? Operational Semantics What is semantics? 2 / 13 What is the meaning of a program? Recall: aspects of a language syntax: the structure of its programs
More informationApplying Experiences with Declarative Codifications of Software Architectures on COD
Applying Experiences with Declarative Codifications of Software Architectures on COD Position Paper Roel Wuyts Stéphane Ducasse Gabriela Arévalo roel.wuyts@iam.unibe.ch ducasse@iam.unibe.ch arevalo@iam.unibe.ch
More informationSmall Formulas for Large Programs: On-line Constraint Simplification In Scalable Static Analysis
Small Formulas for Large Programs: On-line Constraint Simplification In Scalable Static Analysis Isil Dillig, Thomas Dillig, Alex Aiken Stanford University Scalability and Formula Size Many program analysis
More informationAdvanced MEIC. (Lesson #18)
Advanced Programming @ MEIC (Lesson #18) Last class Data races Java Memory Model No out-of-thin-air values Data-race free programs behave as expected Today Finish with the Java Memory Model Introduction
More informationFoundations. Yu Zhang. Acknowledgement: modified from Stanford CS242
Spring 2013 Foundations Yu Zhang Acknowledgement: modified from Stanford CS242 https://courseware.stanford.edu/pg/courses/317431/ Course web site: http://staff.ustc.edu.cn/~yuzhang/fpl Reading Concepts
More informationModularizing Web Services Management with AOP
Modularizing Web Services Management with AOP María Agustina Cibrán, Bart Verheecke { Maria.Cibran, Bart.Verheecke@vub.ac.be System and Software Engineering Lab Vrije Universiteit Brussel 1. Introduction
More informationmodel-driven development Separation of Concerns in Model-Driven Development
focus model-driven development Separation of Concerns in Model-Driven Development Vinay Kulkarni and Sreedhar Reddy, Tata Research Development and Design Centre To facilitate traceability, reuse, and evolution,
More information& Object-Oriented Programming (POOP) Modified from CS61A Summer 2012 Lecture at UC Berkeley
& Object-Oriented Programming (POOP) Modified from CS61A Summer 2012 Lecture at UC Berkeley Where We Were: Functional Programming Style of programming One of many programming paradigms where functions
More informationRefactoring. Paul Jackson. School of Informatics University of Edinburgh
Refactoring Paul Jackson School of Informatics University of Edinburgh Refactoring definition Refactoring (noun) is a change made to the internal structure of software to make it easier to understand,
More informationTypeChef: Towards Correct Variability Analysis of Unpreprocessed C Code for Software Product Lines
TypeChef: Towards Correct Variability Analysis of Unpreprocessed C Code for Software Product Lines Paolo G. Giarrusso 04 March 2011 Software product lines (SPLs) Feature selection SPL = 1 software project
More informationAn Attribute Graph Grammar for UML Package Diagrams and its Applications
An Attribute Graph Grammar for UM Package Diagrams and its Applications akaaki Goto 1, etsuro Nishino 2, and Kensei suchida 1 Center for Industrial and Governmental elations, he University of Etro-Communications,
More informationOrchestration vs Choreography
Orchestration vs Choreography u In many cases, there is no unique point of invocation for the services n In these cases, we say that the system is a choreography n Let starts with an example: w Consider
More informationStatic rules of variable scoping in Erlang
Proceedings of the 7 th International Conference on Applied Informatics Eger, Hungary, January 28 31, 2007. Vol. 2. pp. 137 145. Static rules of variable scoping in Erlang László Lövei, Zoltán Horváth,
More informationchallenges in domain-specific modeling raphaël mannadiar august 27, 2009
challenges in domain-specific modeling raphaël mannadiar august 27, 2009 raphaël mannadiar challenges in domain-specific modeling 1/59 outline 1 introduction 2 approaches 3 debugging and simulation 4 differencing
More informationCS4215 Programming Language Implementation. Martin Henz
CS4215 Programming Language Implementation Martin Henz Thursday 26 January, 2012 2 Chapter 4 The Language simpl In this chapter, we are exting the language epl in order to provide a more powerful programming
More informationOutline. Software Rots
Outline Design Principles: Part 1 ENGI 5895: Software Design 1 The Need for Design Principles Andrew Vardy 2 Refactoring Faculty of Engineering & Applied Science Memorial University of Newfoundland January
More informationObjects as a programming concept
Objects as a programming concept IB Computer Science Content developed by Dartford Grammar School Computer Science Department HL Topics 1-7, D1-4 1: System design 2: Computer Organisation 3: Networks 4:
More informationBluespec-4: Rule Scheduling and Synthesis. Synthesis: From State & Rules into Synchronous FSMs
Bluespec-4: Rule Scheduling and Synthesis Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology Based on material prepared by Bluespec Inc, January 2005 March 2, 2005
More informationA Comparison of Software Refactoring Tools
A Comparison of Software Refactoring Tools Jocelyn Simmonds Ecole des Mines de Nantes jocelyn.simmonds@eleve.emn.fr Tom Mens Vrije Universiteit Brussel tom.mens@vub.ac.be November 25, 2002 Abstract The
More informationTopic 7: Inheritance. Reading: JBD Sections CMPS 12A Winter 2009 UCSC
Topic 7: Inheritance Reading: JBD Sections 7.1-7.6 1 A Quick Review of Objects and Classes! An object is an abstraction that models some thing or process! Examples of objects:! Students, Teachers, Classes,
More informationScenario-based Refactoring Selection
BABEŞ-BOLYAI University of Cluj-Napoca Faculty of Mathematics and Computer Science Proceedings of the National Symposium ZAC2014 (Zilele Academice Clujene, 2014), p. 32-41 Scenario-based Refactoring Selection
More informationImplementing evolution: Refactoring
2IS55 Software Evolution Sources Implementing evolution: Refactoring Alexander Serebrenik / SET / W&I 17-5-2010 PAGE 1 Last week Problem: changing code is difficult Assignment 6 Deadline: Today Assignment
More informationMatching Program Elements for Multi-Version Program Analyses
Matching Program Elements for Multi-Version Program Analyses Miryung Kim, David Notkin University of Washington The Third International Workshop on Mining Software Repositories, Shanghai China, 2006 Multi-Version
More information