Service Oriented Architecture Definition Using Composition of Business-Driven Fragments

International audienceServices Oriented Architecture are built through the compo- sition of services (e.g. Web Services) to define complex business process (e.g. Orchestrations). Well known methodologies focus on identifying ser- vices and orchestrations at design time. However the orchestration design phase is still a heavy burden, as it induces to deal with both technical and business domain concerns. This article proposes to use an evolution framework (Adore) to capitalize architects knowledge and best practices into “evolutions”. Architects can build business-driven orchestrations by composing reusable “evolutions” following a design–by–composition ap- proach. We apply this approach to build a legacy Soa called Seduite (validation platform for the French national research project Faros)

Une approche orientée aspect allant du modèle d'exigences au modèle de conception

National audienceDes approches orientées aspects sont aujourd'hui disponibles à chaque phase du développement d'un logiciel : analyse des exigences, conception, ou encore implémentation. Passer d'une phase à l'autre en conservant les aspects identifiés au préalable reste un défi majeur, pourtant peu étudié. Nous proposons dans un article publié à AOSD'11 une approche itérative et dirigée par les préoccupations, permettant de transformer un modèle d'exigences orienté aspect en un modèle de conception lui aussi orienté aspect, et ceci de manière automatique. Cette ap- proche est mise en œuvre en utilisant AoURN ("use case maps") pour le modèle d'exigence et Adore pour le modèle de conception (orchestrations SOA). Elle permet l'encapsula- tion continue des préoccupations identifiées lors des exigences, transformées en artefact de conception. Nous proposons de plus une boucle de rétro-action permettant de remonter dans les modèles d'exigences des défauts constatés dans le modèle de conception, supportant ainsi un processus de développement itératif

Using Domain Features to Handle Feature Interactions

International audienceSoftware Product Lines in general and feature diagrams in particular support the modeling of software variability. Unfortunately, features may interact with each other, leading to feature interaction issues. Even if detected at the implementation level, interaction resolution choices are part of the business variability. In this paper, we propose to use a stepwise process to deal with feature interactions at the domain level: the way an interaction is resolved is considered as a variation point in the configuration process. This method and the associated implementation are applied onto a concrete case study (the jSeduite information system)

Logiciels pour Pôles Santé de Proximité/Infrastructure de collecte d'information : Etudes

National audienceStand laboratoires : LEAT, I3S, Inria, Faculté de Médecin

Logiciels pour Pôles Santé de Proximité/Infrastructure de collecte d'information : Etudes

National audienceStand laboratoires : LEAT, I3S, Inria, Faculté de Médecin

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

Introducing Security Access Control Policies into Legacy Business Processes

International audienceApplying separation of concerns approaches into business process context generally results in several initiatives oriented to automatic generation of aspect code, generation of specific code according to the kind of concern (code for mapping roles and permissions derived from RBAC model for example), or proposition of new mechanisms as dedicated aspectual languages. Most of these initiatives only consider functional behaviours of business process, omitting special behaviours derived from quality attributes such as security, which can be modelled as concerns that must be supported in the business process. In this paper we propose the integration of cross-cuttings standardized control access policies (based on RBAC model and Oasis XACML) into legacy business processes, using a separation of concerns approach

Vers la construction de workflows pour le filtrage sémantique de nouvelles

National audienceInternet is becoming today a wonderful medium to broadcast informations. While sources are multiplying (RSS, Web Services, ...), the amount of informations is growing and it becomes necessary to filter them according to user interests. Many tools are currently developed that exploits ontologies or thesauri to annotate informations. They enable to query these annotations according to criteria to retrieve only the relevant informations. The composition of these tools constitute workflows that should be enriched by the emergence of new ontologies modeling different domains and text analysis tools. However the composition of these tools-chains is not accessible for everyone. In this paper we show how these workflows are built and present our approach for automatically building workflows based on user needs. This work is supported by the ANR Emergence \Y project dedicated to automate the broadcasting of informations on large screens, and for which the relevance of informations published is important.Le web se révèle aujourd'hui un merveilleux support de diffusion d'informations. Cependant, tandis que les sources se multiplient (flux rss, services web, ..), la quantité d'informations croît et il est nécessaire de les filtrer en fonction des centres d'intérêts des utilisateurs. Actuellement de nombreux outils qui exploitent les ontologies ou les thésaurus sont mis au point. Ils permettent d'annoter les informations, d'en déduire des critères et d'ensuite obtenir uniquement les informations pertinentes. La composition de ces outils constitue des workflows qui devraient encore s'enrichir grâce à l'apparition de nouvelles ontologies ciblées sur différents domaines et outils de lecture. Cependant la construction de telles chaînes logicielles n'est pas à la portée de tous. Dans cet article nous montrons comment de tels workflows ont été construits et présentons nos perspectives en matière de construction automatique de ces workflows en fonction des besoins utilisateur. Ce travail s'appuie sur le projet ANR Emergence \Y qui vise à automatiser la diffusion des informations sur de grands écrans, et pour lequel la pertinence des informations diffusées est donc particulièrement importante

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