Pour profiter des nombreux matériels actuellement, les logiciels s'exécutant sur des téléphones mobiles doivent devenir sensibles au contexte, c'est-à-dire, qu'ils doivent surveiller les événements provenant de leur environnement et réagir en conséquence. Nous considérons que ces logiciels peuvent bénéficier d'une approche basée sur les Lignes de Produits Logiciels (LPL). Les LPLs sont définies pour exploiter les points communs par la définition d'éléments réutilisables. Néanmoins, les LPLs ne prennent pas en compte les modifications à l'exécution des applications. Cette thèse propose une ligne de produits logiciels dynamique (LPLD) qui étend une LPL classique en fournissant des mécanismes pour adapter les produits à l'exécution. Notre objectif principal est d'unifier les adaptations à la conception et à l'exécution en utilisant des artefacts logiciels de haut niveau. Concrètement, nous introduisons un modèle de variabilité et un modèle de composition pour modulariser les produits sous forme de modèles d'aspect. Chaque modèle d'aspect a trois parties : l'architecture, les modifications, et le point de coupe. Ensuite, nous proposons deux processus de dérivation du produit : un pour la conception que vise à construire un produit, et un pour l'exécution que vise à adapter un produit. Ce travail de recherche s'est déroulé dans le cadre du projet FUI CAPPUCINO. Nous avons défini une LPLD pour une étude de cas de vente d'un hypermarché sensible au contexte. Le scénario démontre les avantages de notre approche et, en particulier, l'unification réalisée par les modèles d'aspect utilisés à la fois à la conception et à l'exécution.

Uma Linha de Produtos de Software (LPS) consiste de um conjunto de sistemas de software que compartilham características comuns e satisfazem às necessidades específicas de um segmento particular. Para tornar o processo de instanciação de produtos mais rápido e menos suscetível a erros, o projeto de uma LPS pode adotar a utilização de geradores de aplicação, que podem gerar os artefatos da LPS utilizando uma especificação das variabilidades de um certo produto. Adicionalmente, notase que determinadas características transversais de uma linha de produtos têm potencial de reúso em diferentes domínios, podendo ser implementadas usando a programação orientada a aspectos (POA). Neste trabalho é proposto um processo para o desenvolvimento de LPS e geração automatizada de produtos levando em consideração os interesses transversais existentes em cada domínio de aplicação. Os interesses transversais são as características comuns espalhadas pelas divisões ou módulos do programa de diferentes domínios. O processo aqui proposto tem a finalidade de aumentar o reúso de características de linhas de produtos por meio da POA, permitindo que as LPSs sejam projetadas de forma mais coesa e, consequentemente, facilitando sua manutenção e evolução. Visando diminuir o esforço necessário para a instanciação dos produtos provenientes dessas linhas de produtos, neste trabalho também é apresentada uma extensão do gerador Captor, denominada Captor-AO. Esse gerador fornece suporte ao processo proposto, permitindo a criação de produtos formados por características de diferentes domínios. Por fim, é apresentado um estudo de caso em que é realizada a configuração de um domínio transversal para o interesse de persistência, a definição de um domínio-base compatível com esse domínio transversal e a geração de produtos formados pelas características de ambos os domínios utilizando o gerador estendido Captor-AO / A Software Product Line (SPL) consists of a set of software systems that share common features and fulfill the specific requirements of a particular domain. In order to make the products instantiation process faster and less prone to errors, the project of a SPL can adopt the utilization of application generators, which can can automatically generate the SPL artifacts based on the specification of the variabilities of a particular product. Additionally, it can be noticed that certain crosscutting features of a product line have potencial to be reused in different domains, so they can be implemented using aspect oriented programming (AOP). In this work, a process is proposed for the development of SPLs and automatic generation of products, considering the crosscutting concerns present in each application domain. The crosscutting concerns are related to the common features that are scattered around program divisions or modules of different domains. The process proposed here has the goal of enhancing the reuse of SPL features using AOP, allowing the design of SPL in a more cohesive way and, thus, easing its maintenance and evolution. Aiming at decreasing the effort needed to instantiate products from these SPL, this work also presents an extension to the Captor application generator, named Captor-AO. This generator supports the proposed process, allowing the creation of products composed by features of different domains. Finally, a case study is presented in which Captor-AO is configured with two domains: a crosscutting domain for the persistence concern and a base domain compatible with this crosscutting domain, such that the generation of products can be done by composing features of both domains

With new paradigms in software engineering such as Software Product Lines, scope of reuse is enlarged from implementation upto design, requirements, test-cases, etc. In this thesis an ontology-based approach is proposed as a solution to systematic requirement reuse problem in software product lines, and the approach is supported with a reuse automation tool. A case study is performed on the projects of an industrial software product line using hereby proposed solution and then based on the evaluated metrics it&rsquo / s reported that the content of requirements specifications documents can be prepared upto 80% by derivation of reusable requirements.

Reusability of assets within a family of products is the major goal of Software Product Line Engineering (SPLE), therefore managing variability is an important task in SPLs. Configuration management in the context of software product line engineering is more complicated than that in single systems engineering due to &rdquo / variability in space&rdquo / in addition to &rdquo / variability in time&rdquo / of core assets. In this study, a method for documenting variability in executable configuration items, namely components, is proposed by associating them with the Orthogonal Variability Model (OVM) which introduces variability as a separate model. The main aim is to trace variability in dierent configurations by explicitly documenting variability information for components. The links between OVM elements and components facilitate tool support for product derivation as the components matching the selected variations can be gathered by following the links. The proposed scheme is demonstrated on a case study about a radar GUI variability model.

A software product line (SPL) succeeds because we exploit the similarities between a set of software-intensive systems, together with an understanding of their differences, to reduce development cost, maintenance cost, and user confusion. In SPL engineering, reuse is planned, enabled, and enforced. It is through the development of a set of core assets that reuse is systematically practiced. Requirements assets enhance the effectiveness of reuse since engineers can work on the abstractions closer to the systems' initial concepts. Contemporary SPL requirements engineerin (RE) approaches often adopt the proactive model to build a relatively complete and stable asset base. In practice, the substantial up-front effort and the abrupt transition from existing practices associated with the proactive model present a prohibitive SPL adoption barrier for many organizations that could otherwise benefit. The extractive model overcomes these shortcomings by reusing existing products for the SPL's initial baseline. In this thesis, we present a framework for applying lightweight techniques to extract, model, and analyze a SPL's requirements assets. We define the notion of functional requirements profiles (FRPs) according to the linguistic characterization of a domain's action-oriented concerns, and show that the FRPs can be extracted from a natural language document on the basis of domain-aware lexical affinities that bear a 'verb - direct object' relation. We model the extracted FRPs by analyzing their semantic cases and by extending the orthogonal variability model (OVM). We contribute a set of heuristic rules for uncovering the variation dimensions and dependencies, and discuss merging the OVMs extracted from multiple sources. We relate functional profiles to quality requirements via scenarios, and manage requirements interactions via concept analysis. We present two applications of FRPs to support some other activities in SPL engineering. We conduct several empirical studies to evaluate our framework. The results show that our approach allows the engineers to identify the domain elements more easily and develop the domain models more systematically. Our work fills the void with respect to extracting a SPL's requirements assets, and the main thrust of our work is to promote a set of lightweight, low adoption threshold techniques as a critical enabler for practitioners to capitalize on the order-of-magnitude improvements offered by SPL engineering.

A software product line (SPL) consists of a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Together with testing of final deliverable products developed within the SPL, called Integration Testing, particularly important in this context is the way individual hardware as well as software components in an SPL are tested and certified for usage within the SPL. This study investigates specific approaches and techniques proposed in the literature for unit testing in the SPL context. Problems inherent to this issue were studied and possible solutions aiming towards systematic and effective testing of hardware as well as software units in SPLs have been proposed. The specific problems of SPL testing in ASELSAN were investigated in the light of these possible solutions and their applicability as well as their benefits were quantitatively assessed.

A software product line (SPL) succeeds because we exploit the similarities between a set of software-intensive systems, together with an understanding of their differences, to reduce development cost, maintenance cost, and user confusion. In SPL engineering, reuse is planned, enabled, and enforced. It is through the development of a set of core assets that reuse is systematically practiced. Requirements assets enhance the effectiveness of reuse since engineers can work on the abstractions closer to the systems' initial concepts. Contemporary SPL requirements engineerin (RE) approaches often adopt the proactive model to build a relatively complete and stable asset base. In practice, the substantial up-front effort and the abrupt transition from existing practices associated with the proactive model present a prohibitive SPL adoption barrier for many organizations that could otherwise benefit. The extractive model overcomes these shortcomings by reusing existing products for the SPL's initial baseline. In this thesis, we present a framework for applying lightweight techniques to extract, model, and analyze a SPL's requirements assets. We define the notion of functional requirements profiles (FRPs) according to the linguistic characterization of a domain's action-oriented concerns, and show that the FRPs can be extracted from a natural language document on the basis of domain-aware lexical affinities that bear a 'verb - direct object' relation. We model the extracted FRPs by analyzing their semantic cases and by extending the orthogonal variability model (OVM). We contribute a set of heuristic rules for uncovering the variation dimensions and dependencies, and discuss merging the OVMs extracted from multiple sources. We relate functional profiles to quality requirements via scenarios, and manage requirements interactions via concept analysis. We present two applications of FRPs to support some other activities in SPL engineering. We conduct several empirical studies to evaluate our framework. The results show that our approach allows the engineers to identify the domain elements more easily and develop the domain models more systematically. Our work fills the void with respect to extracting a SPL's requirements assets, and the main thrust of our work is to promote a set of lightweight, low adoption threshold techniques as a critical enabler for practitioners to capitalize on the order-of-magnitude improvements offered by SPL engineering.

<p>This report presents the results of a thesis project that surveys and designs about the issue “Feature Model for Adaptive Computing”. In this project, there are two main issues, first one is about the Feature Modeling, and the second is how to use this Feature Modeling for adaptive computing.</p><p>In this thesis report, at the beginning, we present the problem we expected to solve and introduce some background information, including the knowledge of feature model and adaptive computing. Then we explain our solution and evaluate this solution. At the end of this report, we give a short conclusion about our thesis project and feature work.</p>

Many organizations specialize in the development of families of software systems, called software product lines (SPLs), for one or more domains (e.g., automotive, telephony, health care). SPLs are commonly developed as a shared set of assets representing the common and variable aspects of an SPL, and individual products are constructed by assembling the right combinations of assets. The feature-oriented software development (FOSD) paradigm advocates the use of system features as the primary unit of commonality and variability among the products of an SPL. A feature represents a coherent and identifiable bundle of system functionality, such as call waiting in telephony and cruise control in an automobile. Furthermore, FOSD aims at feature-oriented artifacts (FOAs); that is, software-development artifacts that explicate features, so that a clear mapping is established between a feature and its representation in different artifacts. The thesis first identifies the problem of developing a suitable language for expressing feature-oriented models of the functional requirements of an SPL, and then presents the feature-oriented requirements modelling language (FORML) as a solution to this problem. FORML's notation is based on standard software-engineering notations (e.g., UML class and state-machine models, feature models) to ease adoption by practitioners, and has a precise syntax and semantics to enable analysis. The novelty of FORML is in adding feature-orientation to state-of-the-art requirements modelling approaches (e.g., KAOS), and in the systematic treatment of modelling evolutions of an SPL via enhancements to existing features. An existing feature can be enhanced by extending or modifying its requirements. Enhancements that modify a feature's requirements are called intended feature interactions. For example, the call waiting feature in telephony intentionally overrides the basic call service feature's treatment of incoming calls when the subscriber is already involved in a call. FORML prescribes different constructs for specifying different types of enhancements in state-machine models of requirements. Furthermore, unlike some prominent approaches (e.g., AHEAD, DFC), FORML's constructs for modelling intended feature interactions do not depend on the order in which features are composed; this can lead to savings in analysis costs, since only one rather than (possibly) multiple composition orders need to be analyzed. A well-known challenge in FOSD is managing feature interactions, which, informally defined, are ways in which different features can influence one another in defining the overall properties and behaviours of their combination. Some feature interactions are intended, as described above, while other feature interactions are unintended: for example, the cruise control and anti-lock braking system features of an automobile may have incompatible affects on the automobile's acceleration, which would make their combination inconsistent. Unintended feature interactions should be detected and resolved. To detect unintended interactions in models of feature behaviour, we must first define a taxonomy of feature interactions for the modelling language: that is, we must understand the different ways that feature interactions can manifest among features expressed in the language. The thesis presents a taxonomy of feature interactions for FORML that is an adaptation of existing taxonomies for operational models of feature behaviour. The novelty of the proposed taxonomy is that it presents a definition of behaviour modification that generalizes special cases found in the literature; and it enables feature-interaction analyses that report only unintended interactions, by excluding interactions caused by FORML's constructs for modelling intended feature interactions.

[pt] Nesta tese investigou-se o desenvolvimento de software no contexto de groupware, especificamente para apoiar a aprendizagem colaborativa. O desenvolvimento de groupware, entretanto, não é trivial. Como todo software, há aspectos tecnológicos e sociais envolvidos no desenvolvimento. Quanto aos aspectos tecnológicos, o desenvolvimento de artefatos de infraestrutura ocupam grande parte do esforço destinado à implementação dessas aplicações, sobrando pouco tempo para a implementação de soluções inovadoras para as questões da colaboração propriamente ditas. Com respeito aos aspectos sociais, deve-se levar em conta que o trabalho em grupo é dinâmico e a composição dos grupos, bem como suas características, se alteram com o passar do tempo. Assim, desenvolveu-se uma linha de produtos de software para groupware baseado no Modelo 3C de Colaboração, onde os groupware são derivados a partir da formalização de técnicas de aprendizagem colaborativa em scripts de colaboração. Foi desenvolvido um protótipo, o GroupwareBuilder para interpretar o script de colaboração e derivar o groupware para suporte específico das suas atividades. Uma avaliação funcional e um estudo de caso foram realizados. Na avaliação funcional, buscou-se obter uma prova de conceito do GroupwareBuilder, na qual dois groupware foram derivados para apoiar os scripts de colaboração Debate Crítico e Buzz Groups. O estudo de caso foi realizado para observar como se daria a derivação de groupware para técnicas de aprendizagem colaborativa modeladas por diferentes professores. A principal contribuição deste trabalho é uma abordagem que possibilita a derivação e adaptação de groupware a partir de scripts de colaboração elaborados pelos usuários e não a partir de uma lista de requisitos funcionais, como em LPS’s tradicionais. / [en] In this thesis we explore software development on the context of groupware, specifically on supporting collaborative learning. Groupware development is not a trivial task given that technological and social issues are involved. Considering the technological issues, a huge amount of time is wasted on implementing infrastructure aspects leaving little time for implementation of innovative solutions on collaboration. Considering the social issues, we should take into account that group work is dynamic and that group composition changes over time. So, we developed a software product line for groupware based on the 3C Collaboration Model. The groupware derivation process starts with the formalization of the collaborative learning techniques in collaboration scripts. In order to support this collaboration process we developed the GroupwareBuilder, that reads the collaboration script and derives groupware tailored to the tasks described on the script. We made a functional evaluation and a case study. On the functional evaluation, we aimed on getting a proof of concept for GroupwareBuilder by deriving groupware for supporting the Critical Debate and Buzz Groups collaboration scripts. In order to analyze how GroupwareBuilder derives groupware from other collaborative learning techniques described by different teachers we made a case study. The main contribution of this thesis is an approach that enables the derivation of groupware and the customization of groupware in runtime from collaboration scripts written by the users, and not from a list of software requirements as used in other SPLs approaches.