1. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 1 Product Lines – Tools and Architecture – Session 1

2. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 2 Product Lines – Tools and Architecture – Session 1 To what extent can we expect the FLOSS world to be interested un variability modeling tools at the product level ? More interested at the user level (not for pure coders). Why ? Low trust on tools, as many modeling tools (open source) are immature or incomplete. Is that going to change in the future, once the tools become mature ? Nowaday, expensive propietary tools. Worlds (PL variability tools vs. comunities): 1- Wild open source community - not interested. 2- FLOSS community producing modeling tools should be interested 3- Industrial embedded development is much more organized and disciplined than "wild FLOSS" - coming from HW development, where reuse and modeling are natural. Interested. 4- When tools are part of the product, requirements from user point of view. The user defines the product, and gets more control on the product. Visual approach to the service definition. High interest.

3. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 3 Product Lines – Tools and Architecture – Session 1 Is it possible to establish an open source community around variability modelling tools ? Interest is there, but needs to address the right people. Interest on configuration tools, release etc. Should we start from a community that shares interest on future architectures ? Start from policy makers ? Key point, linking the architects with similar visions in communities. If the discussion is too theoretical we should link tools with common architecture views, and in a practical and tangible way.

4. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 4 Product Lines – Tools and Architecture – Session 1 Common architecture views will provide the baseline to use SPL tools against specific platforms. Linking tools with specific platforms is important. There are always architects, even if not called that way. Pros and cons for SPL tools in this context: CON: In some cases there is no clear separation between platform and application, PRO:...although plug-in schemas are predominant (meaning some level of abstraction). PRO: Trend, to have a thin platform layer, just for the plugin framework. CON: Less distinction between domain and middleware applications. Same architecture for infrastructure and domain software. Specific to embedded systems, two conflicting trends: CON: Low trust on code generation PRO: Support for modeling as natural activity PRO: As complexity grows, more abstraction required.

5. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 5 Product Lines – Tools and Architecture – Session 1 Back to generic considerations: PRO: FLOSS should help to generate more trust on code, as it is transparent CON: Barrier, additional costs on modeling and source code generator maintenance. CON: Yet another barrier, companies don't want to support SPL tools that are open source (not the core business) PRO:...but buying a proprietary tool is another risk (married to the provider roadmap etc). CON: Backtracking (retrofitting the SPL) is another barrier (psichological in many cases). CON: More barriers, as using a tool for a long time creates issues as it gets outdated. Difficult to change legacy code and artifacts to a new tool. Economic issue of changing from tool to tool. PRO:...except in FLOSS cases ? (e.g. Topcased Airbus or tools with active and long lasting communities) PRO: a meta-model tool enforcing the architecture would be beneficial (Debian communty checks enforcement with special community-made tools) CON:...but has a con, resistance to modeling tools in general. It would be good to run a detailed diagnosis on pros and cons, to know better the situation.

6. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 6 Product Lines – Tools and Architecture – Session 1 Tools seem appropiate at the user level (domain oriented) For users producing services and middleware (transversal across domain like UPnP and OSGi). Delivering services have topics not relevant at middleware level. MD approach - transforming at 2 levels. Two levels, people working on the application level, others at the infrastructure levels. In the architecture, where do we split application and infrastructure ? Which one is more relevant ? Do they need different tools ? In OSIRIS, 60% of code generated with a simple service from MOSKIKT (modeling) tailored to the specific application domain. ATL for M2M and MOFScript for M2Text. If split, we can make changes in one level (middleware) without affecting application layers. Different targets meaning different communities and possibly architectures. Some willing to invest more than others (application level,more).

7. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 7 Product Lines – Tools and Architecture – Session 1 Variability modeling: Is it a good idea to have separate languages for modeling variability or is it better to combine traditional models ? How to visualize variability and dependencies ? Alternatives: Tree views, UML with OCL,... Dependant on the users of the tools. Middleware could be done with UML (technical views) and users with tree views (application oriented). MoSiS proposes both approaches: metamodel as standard core and tools supporting separate models - Metacase proposing and integrated approach.

8. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 8 Product Lines – Tools and Architecture – Session 1 How to deal with Trade-off analysis in RT embedded systems ? Trade-off analysis in RT embedded, taking in account non-functional constraints of the application in variability resolution time - related to enforcement tools. Guided choices - user resolves functional, system enforces non functional. Quality attributes - another view, transparency attributes of FLOSS is the best quality attribute ? No documentation, issue.

9. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 9 Product Lines – Tools and Architecture – Session 2

10. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 10 Product Lines – Tools and Architecture – Session 1 Topic 1: SPL to Software Service Lines ?  An important part of the software in recent mobile phones is coming from outside. However, mobile phones (and smart devices) are not linked to the service business.  Controlling the variability in services, focusing in tools.  Service Lines. Blurred distinction between service and product.  Big players on the move Hans Petter / Jesús / Joseba / Jeajoon.

11. Frank van der Linden, Björn Lundell, Jesús Bermejo April 2, 2008, Dagstuhl-Seminar 08142/1 11 Product Lines – Tools and Architecture – Session 1 Topic 2: SPL in the wild.  External and open assets in a PL.  Decentralized structures, no core asset " internal team".  Convergence in architecture.  Product becomes a moving target.  The core of the issue is the shift of control to trust. Frank / Anders / Bjorn