This work was partially funded by the RNTL initiative (LUTIN project) 1 Refactoring to Object-Oriented Design Patterns Mikal Ziane (LIP6 and Université.

Slides:



Advertisements
Similar presentations
Charles Consel 1, Fabien Latry 1, and Julien Mercadal 1 IPTComm – July Phoenix Research Group INRIA / LaBRI Staging Telephony.
Advertisements

TWO STEP EQUATIONS 1. SOLVE FOR X 2. DO THE ADDITION STEP FIRST
Object-Oriented Programming Session 9 Course : T Programming Language Concept Year : February 2011.
© 2010 IBM Corporation IBM Research – Haifa Virage Logic Integrating Heterogeneous Components in Software Supply Chains Herman Hartmann, Aart Matsinger,
Introduction to Object Orientation System Analysis and Design
1 Knowledge Representation Introduction KR and Logic.
Design Patterns.
© 2005 by Prentice Hall Chapter 13 Finalizing Design Specifications Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 1: The Database Environment
Chapter 7 System Models.
Requirements Engineering Process
Chapter 27 Software Change.
Chapter 6 Structures and Classes. Copyright © 2006 Pearson Addison-Wesley. All rights reserved. 6-2 Learning Objectives Structures Structure types Structures.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
1 Copyright © 2005, Oracle. All rights reserved. Introducing the Java and Oracle Platforms.
Language Specification using Metamodelling Joachim Fischer Humboldt University Berlin LAB Workshop Geneva
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
0 - 0.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
ADDING INTEGERS 1. POS. + POS. = POS. 2. NEG. + NEG. = NEG. 3. POS. + NEG. OR NEG. + POS. SUBTRACT TAKE SIGN OF BIGGER ABSOLUTE VALUE.
MULT. INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Addition Facts
1 9 Moving to Design Lecture Analysis Objectives to Design Objectives Figure 9-2.
CS4026 Formal Models of Computation Part II The Logic Model Lecture 1 – Programming in Logic.
BALANCING 2 AIM: To solve equations with variables on both sides.
Visual Model-based Software Development EUD-Net Workshop, Pisa, Italy September 23 rd, 2002 University of Paderborn Gregor Engels, Stefan Sauer University.
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design 1.
Configuration management
Eugene Syriani and Huseyin Ergin University of Alabama Software Modeling Lab Software Engineering Group Department of Computer Science College of Engineering.
Chapter 14 Software Testing Techniques - Testing fundamentals - White-box testing - Black-box testing - Object-oriented testing methods (Source: Pressman,
Software Engineering - Specifications 1 Specifications Specification document must be clear, complete and correct.
11 Contracts CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 6)
© 2011 TIBCO Software Inc. All Rights Reserved. Confidential and Proprietary. Towards a Model-Based Characterization of Data and Services Integration Paul.
1 A Formal Foundation for Software Refactoring Tom Mens, Serge Demeyer, Dirk Janssens serge.demeyer | dirk.janssens Programming.
1 UML ++ Mohamed T IBRAHIM University of Greenwich -UK.
Software Processes.
Problem Solving and Algorithm Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
Chapter 11 Software Evolution
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 1: Introduction.
Addition 1’s to 20.
25 seconds left…...
Week 1.
Chapter 11 Component-Level Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering 1.
Towards a Standard Interface for Runtime Inspection in AOP Environments OOPSLA Workshop on Tool for AOSD, Seattle, November 2002 Katharina Mehner and Awais.
Chapter 13 – Introduction to Classes
TM Graphical Monitoring Electronic Service Tools.
Languages for IT & CS Pseudo-code What HTML isn’t Early history Compiling & interpreting Classifying languages The process of programming.
Modeling Main issues: What do we want to build How do we write this down.
From Model-based to Model-driven Design of User Interfaces.
Program Slicing – Based Techniques
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
JDBC Session 4 Tonight: Design Patterns 1.Introduction To Design Patterns 2.The Factory Pattern 3.The Facade Pattern Thursday & Next Tuesday: Data Access.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
Generative Programming. Generic vs Generative Generic Programming focuses on representing families of domain concepts Generic Programming focuses on representing.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Introduction To System Analysis and design
CS 403 – Programming Languages Class 25 November 28, 2000.
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
Generative Programming. Automated Assembly Lines.
1 Introduction to Software Engineering Lecture 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Pattern Bridge. Definition Bridge is the structural pattern that separates abstraction from the implementation so that both of them can be changed independently.
Yu, et al.’s “A Model-Driven Development Framework for Enterprise Web Services” In proceedings of the 10 th IEEE Intl Enterprise Distributed Object Computing.
Chapter 0: Introduction
Presentation transcript:

This work was partially funded by the RNTL initiative (LUTIN project) 1 Refactoring to Object-Oriented Design Patterns Mikal Ziane (LIP6 and Université Paris 5) Nicolas Pierron (LIP6 and LRDE) Context KBSE OO Design Patterns Detecting unwanted coupling Refactoring Perspectives and practical issues

2 Context LIP6 /Network and Distributed Systems Dpt MoVe team –UML/MDA people –Petri net people –Other people People working with me –2 PhD students defended in November –1 PhD student starting (MDA stuff, hopefully DS) –1 co-advised with ETS (Quebec) on DS UML ?

3 Knowledge-based software engineering Software development tools are really poor Communication with developers: at a very low level  Exhibit and integrate developers’ know-how into assistant tools One source of know-how: design patterns Other areas of interest: –Semi-automatic refinement (B, DS over B) –Generation of user interfaces –Control transformations in pi-calculus ? –…

4 Design Patterns Quite successful in disseminating design experience Use a "form that PEOPLE can use effectively" Pattern = name + problem + solution NOT meant to be formalized  Tool support is superficial  The "problem" part is not supported There are more and more patterns  It is hard to find which pattern solves a problem Over-engineering is common => Tool support to match design problems with patterns is required

5 Prototype Pattern Editor Graphic PictureText

6 An anti-pattern for Prototype public Graphic addElement (Icon i) { if ( /* i is a text icon */ ) return new Text(); else return new Picture(); }

7 What design problems ? Two challenges in software engineering: –Complexity –Changes Many design patterns prevent propagation of changes They aim at decoupling clients from services They introduce various kinds of indirections  Use patterns only when needed

8 When are patterns needed ? Agile programming: keep software simple Refactor when maintenance cost increases or might increase What entities will be stable/unstable in the near future ? Our proposal: hide unstable entities from more stable clients using decoupling constraints Express decoupling in terms of static access rights Generalization of OO encapsulation

9 Static Accesses Full name: unambiguously references a program element Occurrence of Access: occurrence of name n in some namespace ns. Uses: relation on NameSpaces x Names. (ns, n)  Uses  ns mentions n at least one. notation : uses (ns,n) Only static accesses are considered: o.m() accesses o and the method m of the static type of o. Dynamic accesses: –heavily used in design patterns –changes in the set of subtypes are managed by the compiler.

10 Access constraints hidden (ns, n)  not uses (ns, n) More complex constraints defined in: –first-order logic –or hybrid modal logic. Developers are expected to use high- level predicates which hide logical expressions

11 High-Level Predicates hiddenClass (c)  // class c is hidden  name  namesOf(c)  client client  c  hidden (client, name) hiddenSubclasses (class)  // the subclasses (or implementers) // of class are hidden  c  subclasses(class), hiddenClass(c) virtualPackage(elements)   name  namesOf(c),  client, client  elements  hidden (client, name)

12 Example public class Editor { private Line aLine; private Text aText; private Picture aPicture; public Editor() { aLine = new Line(); aText = new Text(); aPicture = new Picture(); } public void display () { aLine.draw(); aText.draw(); aPicture.draw(); }

13 Access Graph

14 Result of annotation process public class Editor { private /* */ edit.Line /* */ aLine; private /* */ edit.Text /* */ aText; private /* */ edit.Picture /* */ aPicture; public Editor () { aLine = new /* */ edit.Line /* */(); aText = new /* */ edit.Text /* */(); aPicture = new /* */ edit.Picture /* */(); } public void display() { /* */ aLine.draw() /* */; /* */ aText.draw() /* */; /* */ aPicture.draw() /* */; }

15 Transformations Introduce indirections to remove unwanted accesses Introduce indirection = apply some kind of fold Folds: –define a new abstraction (class, method, interface) or recognize an existing one –replace offending term by instance of abstraction Effect of folds on access graph: uses (ns, n)  {uses (ns, a), uses (a, n)} ns n n a

16 Kinds of folds classical fold –extract-method ; move-method dynamic statement fold –use polymorphic method –the second access relies on dynamic binding data fold –displace data (and related computations) to another class type fold –type inferencing  interface hiding concrete classes

17 Expected result (work in progress) public class Editor { private Graphic aLine; // better : use collection private Graphic aText; private Graphic aPicture; public Editor( Graphic a, Graphic b, Graphic c) { aLine = a.clone(); // better : collection parameter aText = b.clone(); // this example is too artificial aPicture = c.clone(); } public void display () { aLine.draw();// not transformed ! aText.draw();// but infer that Graphic has aPicture.draw();// a draw() method }

18 // this interface is introduced interface Graphic { public Graphic clone(); public void draw(); } // code for clone() is added to concrete classes

19 Results, Implications and Future Work Results –Constraint checking (Stratego + Prolog) works on significant test applications (e.g. JLex) –Several folds implemented using stratego Implications –Now people know what terms must be refactored (to patterns, …) –Developers can check that the problem has been solved ! –Generate-and-test approach becomes possible Future work –Finish implementation of transformations –Define folds more cleanly –Experiment on more patterns and applications –Control combinatorial explosion induced by naive generate-and-test Try CLP Abstract interpretation of transformations on the access graph ?

20 Practical issues Best way to distribute LUTIN ? –Installation issues –Integrate into Stratego build farm ? Future of Dryad ?

21 Other areas of interest Semi-Automatic refinement from domain-specific specification languages –Domain specific B ?? Apply Stratego, Elan(?) –to domain-specific model engineering (DS MDA, DSL TOOLS …) ?