1 / 23

Modern Software Systems

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. Modern Software Systems. Heterogonous artifacts Source code: C, Java, DSLs, … Design documents

vern
Download Presentation

Modern Software Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SPLGraph: Towards a Formalism for Software Product LinesItay MamanIBM Research – HaifaGoetz Botterweck Lero – The Irish software Engineering Research CentreMay 2nd 2010, PLEASE 2010

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

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

  4. 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. Tool Stack: Centralized Variability File Repository P1 configuration Feature Model + Materializer P1 Artifacts Requirements Design Tests … Design Tests … Requirements Design Code Requirements … Review\Edit Variability UI Variability UI Variability UI Variability UI Requirements Tool Design Tool IDE/Compiler …

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

  7. 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. 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. 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. SPLGraph • A directed graph <V,E> • 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. Simple Example: “class a extends b”(no variability) s a b e0 extends

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

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

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

  15. 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. a b s extends subject c e1 f target h g extends t key a b s extends subject c e1 f target condition T h g extends t key Example: “class a extends b” materialize(G,{},{h},s)

  17. f h2 d … e2 s h1 a b f extends e1 subject subject c t target g s1 g1 e3 key extends key target condition f Everything is a Vertex!

  18. 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. Performance: Graph Construction

  20. Scalability

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

  22. 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. Questions ?imaman@il.ibm.comtwitter.com/pembleton

More Related