July 2005REFT workshop, Newcastle1 Some thoughts about product line engineering: using UML, B, and refinement - emerging from CS2/ATEC A research programme arising from EU project IST RODIN Mike Poppleton, Colin Snook (ECS, University of Southampton) { Ian Johnson (AT Engine Controls (ATEC))

July 2005REFT workshop, Newcastle2 ATEC case study – state of play Requirements document = “First-cut” generic model + instance model exists as RODIN deliverable Validated generic static model exists Work in progress/ planned: Construction of validated generic & instance dynamic models –via UML-B, refinement Proposal of refinement (and abstraction ?) patterns for FM domain in product line engineering (PLE) PLE: The engineering, from a generic set of requirements for a given domain, of product instances configured to specific requirements.

July 2005REFT workshop, Newcastle3 One of many issues: feature modelling … from Muthig*

July 2005REFT workshop, Newcastle4 Issues Methodological investigations: in PLE –much emphasis on domain analysis/ engineering –the quest for good generic abstractions modelling variability and commonality and consequent instantiation transformations –(not) surprising degree of difference between PLE domains …

July 2005REFT workshop, Newcastle5 Product instantiation - ATEC 120%0%0% 100%/ sec Engine Stood 120%10 % 100%/ sec Engine Starting 120%50 % 100%/ sec Engine Running 120%0%0% 100%/ sec Engine Stood 120%10 % 100%/ sec Engine Starting 120%50 % 100%/ sec Engine Running + generic + instance product instance

July 2005REFT workshop, Newcastle6 Product line issues - ATEC 12 0% 0%0% 100%/ sec Engine Stood 12 0% 10 % 100%/ sec Engine Starting 12 0% 50 % 100%/ sec Engine Running 12 0% 0%0% 100%/ sec Engine Stood 12 0% 10 % 100%/ sec Engine Starting 12 0% 50 % 100%/ sec Engine Running + generic + instance product instance variability ? instance data management ?

July 2005REFT workshop, Newcastle7 Variability ? + product instantiation decision model

July 2005REFT workshop, Newcastle8 Instance data management ? 120 % 0% 100%/s ec Engine Stood 120 % 10 % 100%/s ec Engine Starting 120 % 50 % 100%/s ec Engine Running 120 % 0% 100%/s ec Engine Stood 120 % 10 % 100%/s ec Engine Starting 120 % 50 % 100%/s ec Engine Running 12 0% 0%0% 100%/ sec Engine Stood 12 0% 10 % 100%/ sec Engine Starting 12 0% 50 % 100%/ sec Engine Running 12 0% 0%0% 100%/ sec Engine Stood 12 0% 10 % 100%/ sec Engine Starting 12 0% 50 % 100%/ sec Engine Running + product instantiation decision model 12 0% 0%0% 100%/ sec Engine Stood 12 0% 10 % 100%/ sec Engine Starting 12 0% 50 % 100%/ sec Engine Running 12 0% 0%0% 100%/ sec Engine Stood 12 0% 10 % 100%/ sec Engine Starting 12 0% 50 % 100%/ sec Engine Running product line feature data product instance feature data

July 2005REFT workshop, Newcastle9 Links to some related work … “preprocessor”-style specification of variability as per Muthig*, applied to UML-B ? a more sophisticated analog of MDA/metamodel approach of Muthig**, i.e. MOF + UML-B ??? Muthig*GoPhone - A Software Product Line in the Mobile Phone Domain Dirk Muthig et al, IESE-Report No /E (Fraunhofer Institut Experimentelles Software Engineering Muthig**Model-Driven Product Line Architectures, SPLC2002, LNCS 2379

July 2005REFT workshop, Newcastle10 More links to related work … Notions of refinement … Wasowski*: refinement (by trace inclusion ) by model restriction from the maximal feature model. A slightly odd notion of refinement Batory*: “feature refinement”: algebraic approache to scaling stepwise refinement: facets, aspects, mixin layers, gluons and origami … A very odd notion of refinement –‘The definition of “refinement” that seems closest to our intended meaning is “the act of making improvement by introducing subtleties or distinctions” (Merriam- Webster’s Dictionary).... At the implementation level, however, a refinement can yield dramatic changes: both the exported functionality (semantics of operations) and the exported interface (signatures of operations) may change. Thus, unlike the use of “refinement” in formal approaches to programming, the set of allowed behaviors of our “refined” program might not be a subset of the behaviors of the “unrefined” program.’ Wasowski* Automatic generation of Program Families by Model Restrictions, SPLC 2004, LNCS 3154 Batory*many papers; see

July 2005REFT workshop, Newcastle11 More links to related work … Notions of refinement … Wasowski*: refinement (by trace inclusion ) by model restriction from the maximal feature model. A slightly odd notion of refinement Batory*: “feature refinement”: algebraic approache to scaling stepwise refinement: facets, aspects, mixin layers, gluons and origami … A very odd notion of refinement –‘The definition of “refinement” that seems closest to our intended meaning is “the act of making improvement by introducing subtleties or distinctions” (Merriam- Webster’s Dictionary).... At the implementation level, however, a refinement can yield dramatic changes: both the exported functionality (semantics of operations) and the exported interface (signatures of operations) may change. Thus, unlike the use of “refinement” in formal approaches to programming, the set of allowed behaviors of our “refined” program might not be a subset of the behaviors of the “unrefined” program.’ –So isn’t this just … retrenchment ? (e.g. Banach, Poppleton 2003) Wasowski* Automatic generation of Program Families by Model Restrictions, SPLC 2004, LNCS 3154 Batory*many papers; see R. Banach, M. Poppleton Retrenching Partial Requirements into System Definitions: A Simple Feature Interaction Case Study, 2003, Req. Eng. J., 8 (4)

July 2005REFT workshop, Newcastle12 This is RODIN-CS2 Looking forward to explorations in … “Product Line Refinement”

July 2005REFT workshop, Newcastle13 Decomposing the example Work

July 2005REFT workshop, Newcastle14 Decomposing the example Work

July 2005REFT workshop, Newcastle15 Decomposing the example Work

July 2005REFT workshop, Newcastle16 Decomposing the example Work