Current situation facing the needs of the scenarios from the deliverables I2.1.1 and I2.2.1

In this document we present the main issues that we have to face in order to define a Software Product Line (SPL) for Broadcasting Systems. These issues were identified through requirement analysis and refactoring of SEDUITE which are described in two internal deliverables: a) D.2.2.1: Introduces the requirements (functional and non-functional) of a Broadcasting System by using a case study based on large gatherings (e.g., concerts, competitions, parties, etc.). b) D.2.1.1: Explains the definition of SEDUITE as a SPL by identifying the different assets and products that make part of it. In particular, from each deliverable different questions were raised. We use these questions to identify the issues that we need to face and to guide the redaction of this document. We classify the questions according to three main topics: (i) user assistance (cf. Section 2), (ii) building and evolution of the SPL (cf. Section 3) and (iii) kinds of variability (cf. Section 4) The questions from the D.2.2.1 deliverable are identified with I.x and those from D.2.1.1 with Q.x. In both cases, the 'x' represents the number of the question in the deliverable. Additionally, we include the results of two questionnaires intended for consumers of information (i.e., professor and students) from broadcasting system in academic institutions

SPLEMMA: A Generic Framework for Controlled-Evolution of Software Product Lines

International audienceManaging in a generic way the evolution process of feature- oriented Software Product Lines (SPLs) is complex due to the number of elements that are impacted and the heterogeneity of the SPLs regarding artifacts used to define them. Existing work presents specific approaches to manage the evolution of SPLs in terms of such artifacts, i.e., assets, feature models and relation definitions. Moreover stakeholders do not necessarily master all the knowledge of the SPL making its evolution difficult and error-prone without a proper tool support. In order to deal with these issues, we introduce SPLEmma, a generic framework that follows a Model Driven Engineering approach to capture the evolution of a SPL independently of the kind of assets, technologies or feature models used for the product derivation. Authorized changes are described by the SPL maintainer and captured in a model used to generate tools that guide the evolution process and preserve the consistency of the whole SPL. We report on the application of our approach on two SPLs: YourCast for digital signage systems, and SALOON, which enables generation of configurations for cloud providers

Current situation facing the needs of the scenarios from the deliverables I2.1.1 and I2.2.1

In this document we present the main issues that we have to face in order to define a Software Product Line (SPL) for Broadcasting Systems. These issues were identified through requirement analysis and refactoring of SEDUITE which are described in two internal deliverables: a) D.2.2.1: Introduces the requirements (functional and non-functional) of a Broadcasting System by using a case study based on large gatherings (e.g., concerts, competitions, parties, etc.). b) D.2.1.1: Explains the definition of SEDUITE as a SPL by identifying the different assets and products that make part of it. In particular, from each deliverable different questions were raised. We use these questions to identify the issues that we need to face and to guide the redaction of this document. We classify the questions according to three main topics: (i) user assistance (cf. Section 2), (ii) building and evolution of the SPL (cf. Section 3) and (iii) kinds of variability (cf. Section 4) The questions from the D.2.2.1 deliverable are identified with I.x and those from D.2.1.1 with Q.x. In both cases, the 'x' represents the number of the question in the deliverable. Additionally, we include the results of two questionnaires intended for consumers of information (i.e., professor and students) from broadcasting system in academic institutions

End-User Modelling

National audienceno abstrac

Interopérabilité des systèmes d'information : approches dirigées par les modèles

National audienceInformation systems are more and more often based on aggregation of other systems that must be maintained and evolved in an agile way and with no entropy creation. This is not without interoperability problems! Among others, the aim of Model-Driven Engineering (MDE) is to provide solutions for interoperability issues between systems. This paper summarizes thoughts that have come up from the specific action "Interoper- ability of information systems and model-driven engineering: What challenges? What solutions?" supported by inforsid. We propose a summary of approaches that are based on MDE and knowledge engineering and that tackle interoperability issues in the industry. Open questions and limitations that raised during the meetings are also reported

Requirements of the SALTY project

This document is the first external deliverable of the SALTY project (Self-Adaptive very Large disTributed sYstems), funded by the ANR under contract ANR-09-SEGI-012. It is the result of task 1.1 of the Work Package (WP) 1 : Requirements and Architecture. Its objective is to identify and collect requirements from use cases that are going to be developed in WP 4 (Use cases and Validation). Based on the study and classification of the use cases, requirements against the envisaged framework are then determined and organized in features. These features will aim at guide and control the advances in all work packages of the project. As a start, features are classified, briefly described and related scenarios in the defined use cases are pinpointed. In the following tasks and deliverables, these features will facilitate design by assigning priorities to them and defining success criteria at a finer grain as the project progresses. This report, as the first external document, has no dependency to any other external documents and serves as a reference to future external documents. As it has been built from the use cases studies that have been synthesized in two internal documents of the project, extracts from the two documents are made available as appendices (cf. appen- dices B and C)

Former à l'égalité : défi pour une mixité véritable

Comprend des référence bibliographique

Uniform and Model-Driven Engineering of Feedback Control Systems

International audienceEngineering and reusing feedback control systems face challenging issues, such as structuring control loops to allow for fine-grained reasoning about their architecture. We propose a model-driven approach in which all major parts of the feedback control are uniformly designed as first-class adaptive elements. Expected properties of the approach are discussed and illustrated on a real scenario of overload control in a grid middleware

SpineFM & TOCSIN : un moteur de raisonnement et son interface de configuration

SpineFM est un outil issu de travaux de recherche sur l’utilisation de lignes de produits logiciels multiples. TOCSIN est l’interface graphique permettant d’exploiter SpineFM.SpineFM se base sur un modèle du domaine défini en EMF et des feature model exploitables par l’outil FAMILIAR afin de définir une ligne de produits logiciels multiples. Des algorithmes spécifiquement écrits permettent ensuite à un utilisateur d’effectuer des actions dans cette ligne multiples en s’assurant de leur cohérence grâce à un mécanisme de propagation. Voir annexe pour complément d’informations