SPLGraph: Towards a Formalism for Software Product Lines Itay Maman IBM Research – Haifa Goetz Botterweck Lero – The Irish software Engineering Research.

Slides:



Advertisements
Similar presentations
TWO STEP EQUATIONS 1. SOLVE FOR X 2. DO THE ADDITION STEP FIRST
Advertisements

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
You have been given a mission and a code. Use the code to complete the mission and you will save the world from obliteration…
Programming with Android: SDK install and initial setup Luca Bedogni Marco Di Felice Dipartimento di Scienze dellInformazione Università di Bologna.
Chapter 1: The Database Environment
Chapter 7 System Models.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 12 Introduction to ASP.NET.
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
Relational Database and Data Modeling
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
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
Title Subtitle.
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.
MULTIPLYING MONOMIALS TIMES POLYNOMIALS (DISTRIBUTIVE PROPERTY)
SUBTRACTING INTEGERS 1. CHANGE THE SUBTRACTION SIGN TO ADDITION
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
Limitations of the relational model 1. 2 Overview application areas for which the relational model is inadequate - reasons drawbacks of relational DBMSs.
1 9 Moving to Design Lecture Analysis Objectives to Design Objectives Figure 9-2.
Layering in Provenance Systems Margo Seltzer May 13, 2009 Provenance in Secure and Advanced Computer Systems.
ZMQS ZMQS
Programming Language Concepts
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
Photo Composition Study Guide Label each photo with the category that applies to that image.
R O O T S Field-Sensitive Points-to-Analysis Eda GÜNGÖR
BT Wholesale October Creating your own telephone network WHOLESALE CALLS LINE ASSOCIATED.
Configuration management
Software change management
11 Contracts CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 6)
Randomized Algorithms Randomized Algorithms CS648 1.
ITEC200 Week04 Lists and the Collection Interface.
ABC Technology Project
© S Haughton more than 3?
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
1 Evaluations in information retrieval. 2 Evaluations in information retrieval: summary The following gives an overview of approaches that are applied.
Squares and Square Root WALK. Solve each problem REVIEW:
Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
1. 2 Captaris Workflow Microsoft SharePoint User Group 16 May 2006.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 1: Introduction.
Executional Architecture
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 14: Simulations 1.
Chapter 5 Test Review Sections 5-1 through 5-4.
GG Consulting, LLC I-SUITE. Source: TEA SHARS Frequently asked questions 2.
Addition 1’s to 20.
25 seconds left…...
1 Object Oriented Programming Ras Bodik, Thibaud Hottelier, James Ide UC Berkeley CS164: Introduction to Programming Languages and Compilers Fall 2010.
Copyright © 2003 by Prentice Hall Computers: Tools for an Information Age Chapter 15 Programming and Languages: Telling the Computer What to Do.
Week 1.
Systems Analysis and Design in a Changing World, Fifth Edition
We will resume in: 25 Minutes.
CS203 Lecture 15.
A SMALL TRUTH TO MAKE LIFE 100%
1 Unit 1 Kinematics Chapter 1 Day
Chapter 11 Component-Level Design
1 PART 1 ILLUSTRATION OF DOCUMENTS  Brief introduction to the documents contained in the envelope  Detailed clarification of the documents content.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 13 Slide 1 Application architectures.
How Cells Obtain Energy from Food
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 14: Protection.
Excel Lesson 16 Protecting, Tracking, and Sharing Workbooks Microsoft Office 2010 Advanced Cable / Morrison 1.
The PLASTIC Model to HUTN transformation tool UDA.
1 Implementing DDIEditor in the Danish Data Archive - Demonstration and gained experience Part of session: Recent Developments in the DDI Implementation.
From Model-based to Model-driven Design of User Interfaces.
Presentation transcript:

SPLGraph: Towards a Formalism for Software Product Lines Itay Maman IBM Research – Haifa Goetz Botterweck Lero – The Irish software Engineering Research Centre May 2 nd 2010, PLEASE 2010

2/23 Modern Software Systems Heterogonous artifacts –Source code: C, Java, DSLs, … –Design documents –User manuals –Licenses –Presentations Heterogonous artifact-specific tools/editors

3/23 …IDE/Compiler Design Tool Requirements Tool Multi Product Tool Stack Variability RequirementsDesignTests… Feature Model P1 configuration Variability Requirements Design Tests Code … … P1 Artifacts Review\Edit File Repository

4/23 Difficulties Rework: Implementing variability in each tool Lack of system wide traceability Viewers cannot be used without the editors –E.g., Lint cannot be used without a variability-enabled IDE Features are a special construct

5/23 Tool Stack: Centralized Variability Feature Model + Materializer P1 configuration …IDE/Compiler Design Tool Requirements Tool Variability UI RequirementsDesignTests… Requirements Design Tests Code … … P1 Artifacts Review\Edit File Repository

6/23 QA Scenario Feature Model + Materializer P1 configuration Compiler DesignTests Design Requirements Tests Code P1 Artifacts P1 can now be tested Plain compiler – no variability support File Repository Requirements Tool

7/23 Can Materialization be Centralized? Vision: a dedicated, generic, product line tool –Handles a wide range of artifacts –Relieve tool vendors from implementing variability mechanisms Similar to source control –IDEs do not try to roll out their own source control mechanism –(Other than UI support) –Variability is more difficult – finer granularity

8/23 Striking a balance High Level Representations (E.g., UML) –Operations: deleteClass, replaceClass, deleteRequirement, … –Representation is too Specific => Operations are not generic –(Too many operations to implement) Low Level Representations: Stream of bits –Only three operations: deleteBit(offset), insertBit(offset, value), replaceBit(offset, value) –Sensitivity to changes: when content changes all offsets must be recalculated –(Impractical)

9/23 Wish List Insensitivity to changes –Local changes in content => local changes in representation Generic: A small number of variability operations –Work on all artifacts Self sustainable: Variability can be defined on variability Decidable Solution: A directed, labeled, graph –Requires: A translation scheme (bi directional)

10/23 SPLGraph A directed graph –Defined as a 7-tuple Label function: L(x) : V E String A set of mutation vertices: M A set of decision vertices: D Three special vertices: T, F, X (Formalization & Patterns are in the paper)

11/23 Simple Example: class a extends b (no variability) ab extends s e0

12/23 Mutation Vertex g a g e1 b c subject key target a g e1 b c key target subject apply(g)

13/23 Decision vertex h h a b s f t e1 T condition y x e2 e3

14/23 Traversal from vertex s h a b s f t e1 T condition y x e2 e3

15/23 Algorithm: Materialize Inputs: G, N, P, s – G : An SPLGraph – N, P : Sets of decision vertices (disjoint) – s : A vertex Steps: –Set the decision of all vertices in N to be F (Add a condition edge) –Set the decision of all vertices in P to be T (Ditto) – Q = All vertices reachable from s (respecting the traversal semantics of decision vertices) –For each mutation vertex q in Q do apply(q)

16/23 Example: class a extends b h a g extends b c s f t subject key target e1 materialize(G,{},{h},s) h a g extends b c s f t subject key target e1 T condition

17/23 Everything is a Vertex! h1a g f extends b c s f t subject key target s1g1 condition key e1 e3 target subject h2 e2 d f …

18/23 Prototype Tool Can Import existing Java Code Program elements can be marked as optional –Field, Method, Class, Package Materialize => Generates a new program –Some of the optional elements are excluded –Determined by a user decision –The algorithm has no Java knowledge! –Can be extended by writing new translators

19/23 Performance: Graph Construction

20/23 Scalability

21/23 Future Product line support in IBM/Rational Jazz platform –First steps: Rhapsody Source Control vs. Product Lines Graph-oriented Database Streamlining the translation schemes API

22/23 Summary Simplicity: A single kind of transformation –Namely: Edge rerouting Self-sustainability: Everything is a vertex –The model can define variability on itself –Similar to the Object-model of object-oriented languages –(See: Smalltalk) Decoupling materialization from artifacts

23/23 Questions ? twitter.com/pembleton