We propose a Capabilities-based approach for constructing complex emergent systems such that they are change-tolerant, and the development effort promotes change-reduction. The inherent complexity of software systems increases their susceptibility to change when subjected to the vagaries of user needs, technology advances, market demands and other change inducing factors. Despite the inevitability of change, traditional Requirements Engineering strives to develop systems based on a fixed solution. This is a mostly unsuccessful approach as evidenced by the history of system failures. In contrast, we utilize Capabilities — functional abstractions that are neither as amorphous as user needs nor as rigid as system requirements — to architect systems to accommodate change with minimum impact. These entities are designed to exhibit desirable characteristics of high cohesion, low coupling and balanced abstraction levels. Capabilities are generated by a two-phased process called Capabilities Engineering. Phase I mathematically exploits the structural semantics of the Function Decomposition graph — a representation of user needs — to formulate change-tolerant Capabilities. Phase II optimizes these Capabilities to conform to schedule and technology constraints. Results from an empirical evaluation of a real-world Course Evaluation System indicate, with statistical significance, that a Capabilities-based design is more change-tolerant than a requirements-based design. In addition, we observe that the use of the CE process inherently reduces change, otherwise generated, during the regular development effort. Empirical analysis on the change-requests of Sakai, a complex emergent system, supports this claim. Finally, we observe that the process of Capabilities Engineering assists in pre-requirement specification traceability by bridging the complexity gap between the problem and solution spaces. / Ph. D.

Software Product Lines (SPLs) and Software Ecosystems (SECOs) are approaches to capturing families of closely related software systems in terms of common and variable functionality (variability in space). SPLs and especially SECOs are subject to software evolution to adapt to new or changed requirements resulting in different versions of the software family and its variable assets (variability in time). Both dimensions may be interconnected (e.g., through version incompatibilities) and, thus, have to be handled simultaneously as not all customers upgrade their respective products immediately or completely. However, there currently is no integrated approach allowing variant derivation of features in different version combinations. In this thesis, remedy is provided in the form of an integrated approach making contributions in three areas: (1) As variability model, Hyper-Feature Models (HFMs) and a version-aware constraint language are introduced to conceptually capture variability in time as features and feature versions. (2) As variability realization mechanism, delta modeling is extended for variability in time, and a language creation infrastructure is provided to devise suitable delta languages. (3) For the variant derivation procedure, an automatic version selection mechanism is presented as well as a procedure to derive large parts of the application order for delta modules from the structure of the HFM. The presented integrated approach enables derivation of concrete software systems from an SPL or a SECO where both features and feature versions may be configured.

Software Product Lines (SPLs) and Software Ecosystems (SECOs) are approaches to capturing families of closely related software systems in terms of common and variable functionality (variability in space). SPLs and especially SECOs are subject to software evolution to adapt to new or changed requirements resulting in different versions of the software family and its variable assets (variability in time). Both dimensions may be interconnected (e.g., through version incompatibilities) and, thus, have to be handled simultaneously as not all customers upgrade their respective products immediately or completely. However, there currently is no integrated approach allowing variant derivation of features in different version combinations. In this thesis, remedy is provided in the form of an integrated approach making contributions in three areas: (1) As variability model, Hyper-Feature Models (HFMs) and a version-aware constraint language are introduced to conceptually capture variability in time as features and feature versions. (2) As variability realization mechanism, delta modeling is extended for variability in time, and a language creation infrastructure is provided to devise suitable delta languages. (3) For the variant derivation procedure, an automatic version selection mechanism is presented as well as a procedure to derive large parts of the application order for delta modules from the structure of the HFM. The presented integrated approach enables derivation of concrete software systems from an SPL or a SECO where both features and feature versions may be configured.:I. Context and Preliminaries 1. The Configurable TurtleBot Driver as Running Example 1.1. TurtleBot: A Domestic Service Robot 1.2. Configurable Driver Functionality 1.3. Software Realization Artifacts 1.4. Development History of the Driver Software 2. Families of Variable Software Systems 2.1. Variability 2.1.1. Variability in Space and Time 2.1.2. Internal and External Variability 2.2. Manifestations of Configuration Knowledge 2.2.1. Variability Models 2.2.2. Variability Realization Mechanisms 2.2.3. Variability in Realization Assets 2.3. Types of Software Families 2.3.1. Software Product Lines 2.3.2. Software Ecosystems 2.3.3. Comparison of Software Product Lines and Software Ecosystems 3. Fundamental Approaches and Technologies of the Thesis 3.1. Model-Driven Software Development 3.1.1. Metamodeling Levels 3.1.2. Utilizing Models in Generative Approaches 3.1.3. Representation of Languages using Metamodels 3.1.4. Changing the Model-Representation of Artifacts 3.1.5. Suitability of Model-Driven Software Development 3.2. Fundamental Variability Management Techniques of the Thesis 3.2.1. Feature Models as Variability Models 3.2.2. Delta Modeling as Variability Realization Mechanism 3.2.3. Variant Derivation Process of Delta Modeling with Feature Models 3.3. Constraint Satisfaction Problems 3.4. Scope 3.4.1. Problem Statement 3.4.2. Requirements 3.4.3. Assumptions and Boundaries II. Integrated Management of Variability in Space and Time 4. Capturing Variability in Space and Time with Hyper-Feature Models 4.1. Feature Models Cannot Capture Variability in Time 4.2. Formal Definition of Feature Models 4.3. Definition of Hyper-Feature Models 4.4. Creation of Hyper-Feature Model Versions 4.5. Version-Aware Constraints to Represent Version Dependencies and Incompatibilities 4.6. Hyper-Feature Models are a True Extension to Feature Models 4.7. Case Study 4.8. Demarcation from Related Work 4.9. Chapter Summary 5. Creating Delta Languages Suitable for Variability in Space and Time 5.1. Current Delta Languages are not Suitable for Variability in Time 5.2. Software Fault Trees as Example of a Source Language 5.3. Evolution Delta Modules as Manifestation of Variability in Time 5.4. Automating Delta Language Generation 5.4.1. Standard Delta Operations Realize Usual Functionality 5.4.2. Custom Delta Operations Realize Specialized Functionality 5.5. Delta Language Creation Infrastructure 5.5.1. The Common Base Delta Language Provides Shared Functionality for all Delta Languages 5.5.2. Delta Dialects Define Delta Operations for Custom Delta Languages 5.5.3. Custom Delta Languages Enable Variability in Source Languages 5.6. Case Study 5.7. Demarcation from Related Work 5.8. Chapter Summary 6. Deriving Variants with Variability in Space and Time 6.1. Variant Derivation Cannot Handle Variability in Time 6.2. Associating Features and Feature Versions with Delta Modules 6.3. Automatically Select Versions to Ease Configuration 6.4. Application Order and Implicitly Required Delta Modules 6.4.1. Determining Relevant Delta Modules 6.4.2. Forming a Dependency Graph of Delta Modules 6.4.3. Performing a Topological Sorting of Delta Modules 6.5. Generating Variants with Versions of Variable Assets 6.6. Case Study 6.7. Demarcation from Related Work 6.8. Chapter Summary III. Realization and Application 7. Realization as Tool Suite DeltaEcore 7.1. Creating Delta Languages 7.1.1. Shared Base Metamodel 7.1.2. Common Base Delta Language 7.1.3. Delta Dialects 7.2. Specifying a Software Family with Variability in Space and Time 7.2.1. Hyper-Feature Models 7.2.2. Version-Aware Constraints 7.2.3. Delta Modules 7.2.4. Application-Order Constraints 7.2.5. Mapping Models 7.3. Deriving Variants 7.3.1. Creating a Configuration 7.3.2. Collecting Delta Modules 7.3.3. Ordering Delta Modules 7.3.4. Applying Delta Modules 8. Evaluation 8.1. Configurable TurtleBot Driver Software 8.1.1. Variability in Space 8.1.2. Variability in Time 8.1.3. Integrated Management of Variability in Space and Time 8.2. Metamodel Family for Role-Based Modeling and Programming Languages 8.2.1. Variability in Space 8.2.2. Variability in Time 8.2.3. Integrated Management of Variability in Space and Time 8.3. A Software Product Line of Feature Modeling Notations and Constraint Languages 8.3.1. Variability in Space 8.3.2. Variability in Time 8.3.3. Integrated Management of Variability in Space and Time 8.4. Results and Discussion 8.4.1. Results and Discussion of RQ1: Variability Model 8.4.2. Results and Discussion of RQ2: Variability Realization Mechanism 8.4.3. Results and Discussion of RQ3: Variant Derivation Procedure 9. Conclusion 9.1. Discussion 9.1.1. Supported Evolutionary Changes 9.1.2. Conceptual Representation of Variability in Time 9.1.3. Perception of Versions as Incremental 9.1.4. Version Numbering Schemes 9.1.5. Created Delta Languages 9.1.6. Scalability of Approach 9.2. Possible Future Application Areas 9.2.1. Extend to Full Software Ecosystem Feature Model 9.2.2. Model Software Ecosystems 9.2.3. Extract Hyper-Feature Model Versions and Record Delta Modules 9.2.4. Introduce Metaevolution Delta Modules 9.2.5. Support Incremental Reconfiguration 9.2.6. Apply for Evolution Analysis and Planning 9.2.7. Enable Evolution of Variable Safety-Critical Systems 9.3. Contribution 9.3.1. Individual Contributions 9.3.2. Handling Updater Stereotypes IV. Appendix A. Delta Operation Generation Algorithm B. Delta Dialects B.1. Delta Dialect for Java B.2. Delta Dialect for Eclipse Projects B.3. Delta Dialect for DocBook Markup B.4. Delta Dialect for Software Fault Trees B.5. Delta Dialect for Component Fault Diagrams B.6. Delta Dialect for Checklists B.7. Delta Dialect for the Goal Structuring Notation B.8. Delta Dialect for EMF Ecore B.9. Delta Dialect for EMFText Concrete Syntax Files

Les architectures orientées services (SOA) sont considérées comme le moyen le plus avancé pour réaliser et intégrer rapidement des applications modulaires et flexibles.Dans ce domaine, les plates-formes SOA à disposition des développeurs et des architectes de produits logiciels sont multiples; les deux plus évoluées d'entre elles étant SCA et OSGi.Une application s'appuyant sur l'une de ces plates-formes peut ainsi être assemblée avec le minimum de composants nécessaires à la réalisation de ses tâches, afin de réduire sa consommation de ressources et d'augmenter sa maintenabilité.De plus, ces plates-formes autorisent l'ajout de composants greffons qui n'étaient pas connus lors des phases initiales de la réalisation du produit.Elles permettent ainsi de mettre à jour, d'étendre et d'adapter continuellement les fonctionnalités du produit de base ou des services techniques nécessaires à sa mise en production, sans interruption de service.Ces capacités sont notamment utilisées dans le cadre du paradigme DevOps et, plus généralement, pour mettre en œuvre le déploiement continu d'artefacts.Cependant, l'extensibilité offerte par ces plates-formes peut diminuer la fiabilité globale du système: une tendance forte pour développer un produit est l'assemblage de composants provenant de tierces-parties. De tels composants peuvent être d'une qualité inconnue voire douteuse.En cas d'erreur, de détérioration des performances, etc., il est difficile de diagnostiquer les composants ou combinaisons de composants incriminés.Il devient indispensable pour le producteur d'un logiciel de déterminer la responsabilité des différents composants impliqués dans un dysfonctionnement.Cette thèse a pour objectif de fournir une plate-forme, Cohorte, permettant de concevoir et d'exécuter des produits logiciels extensibles et résilients aux dysfonctionnements d'extensions non qualifiées.Les composants de tels produits pourront être développés dans différents langages de programmation et être déployés (ajout, mise à jour et retrait) en continu et sans interruption de service.Notre proposition adopte pour principe d'isoler les composants considérés comme instables ou peu sûrs.Le choix des composants à isoler peut être décidé par l'équipe de développement et l'équipe opérationnelle, à partir de leur expertise, ou bien déterminé à partir d'une combinaison d'indicateurs.Ces derniers évoluent au cours du temps pour refléter la fiabilité des composants.Par exemple, des composants peuvent être considérés fiables après une période de quarantaine; une mise à jour peut entraîner la dégradation de leur stabilité, etc..Par conséquent, il est indispensable de remettre en cause les choix initiaux dans l'isolation des composants afin, dans le premier cas, de limiter le coup des communications entre composants et, dans le deuxième cas, de maintenir le niveau de fiabilité du noyau critique du produit. / Service-Oriented architectures (SOA) are considered the most advanced way to develop and integrate modular and flexible applications.There are many SOA platforms available for software developers and architects; the most evolved of them being SCA and OSGi.An application based on one of these platforms can be assembled with only the components required for the execution of its tasks, which helps decreasing its resource consumption and increasing its maintainability.Furthermore, those platforms allow adding plug-ins at runtime, even if they were not known during the early stages of the development of the application.Thus, they allow updating, extending and adapting the features of the base product or of the technical services required for its execution, continuously and without outage.Those capabilities are applied in the DevOps paradigm and, more generally, to implement the continuous deployment of artifacts.However, the extensibility provided by those platforms can decrease the overall reliability of the system: a strong tendency in software development is the assembly of third-parties components.Such components may be of unknown or even questionable quality.In case of error, deterioration of performance, ... it is difficult to identify the implicated components or combinations of components.It becomes essential for the software producer to determine the responsibility of the various components involved in a malfunction.This thesis aims to provide a platform, Cohorte, to design and implement scalable software products, resilient to malfunctions of unqualified extensions.The components of such products may be developed in various programming languages and be deployed continuously (adding, updating and withdrawal) and without interruption of service.Our proposal adopts the principle of isolating the components considered unstable or insecure.The choice of the components to be isolated may be decided by the development team and the operational team, from their expertise, or determined from a combination of indicators.The latters evolve over time to reflect the reliability of components.For example, components can be considered reliable after a quarantine period; an update may result in deterioration of stability, ...Therefore, it is essential to question the initial choices in isolating components to limit, in the first case, the scope of communications between components and, in the second case, to maintain the reliability of the critical core of the product.

Este trabalho discorre sobre o estudo da utilização do método de avaliação ATAM como referência para um roteiro para evolução arquitetural. O estudo apresentado está dividido em duas partes: a elaboração de um roteiro para evolução de software e a aplicação do roteiro em um ambiente real de um sistema para automação de linhas aéreas. O objetivo é avaliar o uso do método de avaliação de arquitetura para direcionar a evolução do software. As diretrizes geradas neste trabalho orientam as ações a serem tomadas com base em evidências obtidas pela avaliação, possibilitando ao software que exiba os atributos de qualidade desejados. / This paper discusses the study of the use of ATAM evaluation method as a reference to a roadmap for architectural evolution. The present study is divided into two parts: the preparation of a roadmap for software development and implementation of the roadmap in a real environment of a system for automation of airlines. The goal is to evaluate the use of architecture evaluation method to direct the evolution of software. The guidelines generated in this work have guided the actions to be taken based on evidence obtained by the evaluation, enabling the software that displays the desired quality attributes.

O custo de serviços na Internet tem encorajado o uso de cache a nível de aplicação para suprir as demandas dos usuários e melhorar a escalabilidade e disponibilidade de aplicações. Cache a nível de aplicação, onde desenvolvedores manualmente controlam o conteúdo cacheado, tem sido adotada quando soluções tradicionais de cache não são capazes de atender aos requisitos de desempenho desejados. Apesar de sua crescente popularidade, este tipo de cache é tipicamente endereçado de maneira ad-hoc, uma vez que depende de detalhes específicos da aplicação para ser desenvolvida. Dessa forma, tal cache consiste em uma tarefa que requer tempo e esforço, além de ser altamente suscetível a erros. Esta dissertação avança o trabalho relacionado a cache a nível de aplicação provendo uma compreensão de seu estado de prática e automatizando a identificação de conteúdo cacheável, fornecendo assim suporte substancial aos desenvolvedores para o projeto, implementação e manutenção de soluções de caching. Mais especificamente, este trabalho apresenta três contribuições: a estruturação de conhecimento sobre caching derivado de um estudo qualitativo, um levantamento do estado da arte em abordagens de cache estáticas e adaptativas, e uma técnica que automatiza a difícil tarefa de identificar oportunidades de cache O estudo qualitativo, que envolveu a investigação de dez aplicações web (código aberto e comercial) com características diferentes, permitiu-nos determinar o estado de prática de cache a nível de aplicação, juntamente com orientações práticas aos desenvolvedores na forma de padrões e diretrizes. Com base nesses padrões e diretrizes derivados, também propomos uma abordagem para automatizar a identificação de métodos cacheáveis, que é geralmente realizado manualmente por desenvolvedores. Tal abordagem foi implementada como um framework, que pode ser integrado em aplicações web para identificar automaticamente oportunidades de cache em tempo de execução, com base na monitoração da execução do sistema e gerenciamento adaptativo das decisões de cache. Nós avaliamos a abordagem empiricamente com três aplicações web de código aberto, e os resultados indicam que a abordagem é capaz de identificar oportunidades de cache adequadas, melhorando o desempenho das aplicações em até 12,16%. / Latency and cost of Internet-based services are encouraging the use of application-level caching to continue satisfying users’ demands, and improve the scalability and availability of origin servers. Application-level caching, in which developers manually control cached content, has been adopted when traditional forms of caching are insufficient to meet such requirements. Despite its popularity, this level of caching is typically addressed in an adhoc way, given that it depends on specific details of the application. Furthermore, it forces application developers to reason about a crosscutting concern, which is unrelated to the application business logic. As a result, application-level caching is a time-consuming and error-prone task, becoming a common source of bugs. This dissertation advances work on application-level caching by providing an understanding of its state-of-practice and automating the decision regarding cacheable content, thus providing developers with substantial support to design, implement and maintain application-level caching solutions. More specifically, we provide three key contributions: structured knowledge derived from a qualitative study, a survey of the state-of-the-art on static and adaptive caching approaches, and a technique and framework that automate the challenging task of identifying cache opportunities The qualitative study, which involved the investigation of ten web applications (open-source and commercial) with different characteristics, allowed us to determine the state-of-practice of application-level caching, along with practical guidance to developers as patterns and guidelines to be followed. Based on such patterns and guidelines derived, we also propose an approach to automate the identification of cacheable methods, which is often manually done and is not supported by existing approaches to implement application-level caching. We implemented a caching framework that can be seamlessly integrated into web applications to automatically identify and cache opportunities at runtime, by monitoring system execution and adaptively managing caching decisions. We evaluated our approach empirically with three open-source web applications, and results indicate that we can identify adequate caching opportunities by improving application throughput up to 12.16%. Furthermore, our approach can prevent code tangling and raise the abstraction level of caching.

Este trabalho discorre sobre o estudo da utilização do método de avaliação ATAM como referência para um roteiro para evolução arquitetural. O estudo apresentado está dividido em duas partes: a elaboração de um roteiro para evolução de software e a aplicação do roteiro em um ambiente real de um sistema para automação de linhas aéreas. O objetivo é avaliar o uso do método de avaliação de arquitetura para direcionar a evolução do software. As diretrizes geradas neste trabalho orientam as ações a serem tomadas com base em evidências obtidas pela avaliação, possibilitando ao software que exiba os atributos de qualidade desejados. / This paper discusses the study of the use of ATAM evaluation method as a reference to a roadmap for architectural evolution. The present study is divided into two parts: the preparation of a roadmap for software development and implementation of the roadmap in a real environment of a system for automation of airlines. The goal is to evaluate the use of architecture evaluation method to direct the evolution of software. The guidelines generated in this work have guided the actions to be taken based on evidence obtained by the evaluation, enabling the software that displays the desired quality attributes.

Software systems today face many challenges that were not even imagined decades prior. Challenges including the need to evolve at a very high rate, lifecycle phase drift or erosion, inability to prevent the butterfly effect where the slightest change causes unimaginable side effects throughout the system, lack of discipline to define metrics and use measurement to drive operations, and no "silver bullet" or single solution to solve all the problems of every domain, just to name a few. This is not to say that the issues stated above are the only problems. In fact, it would be impossible to list all possible problems--software itself is infinitely flexible bounded only by the human imagination. These are just a portion of the primary challenges today's software engineer faces. There have been attempts throughout the history of software to resolve each one of these challenges. There have been those who tried to tackle them individually, simultaneously, as well as various combinations of them at one time. One such method was to define and encapsulate the various phases within software, which has come to be called a software lifecycle or lifecycle model. Another area of recent research has lead to the hypothesis that many of these challenges can be resolved or at least facilitated through proper traceability methods. Virtually none of today's software components are completely derived from scratch. Rather, code reuse and software evolution become a large portion of the software engineer's duties. As Vance Hilderman at HighRely puts it, "Research has shown that proper traceability is vital. For high quality and safety-critical engineering development efforts however, traceability is a cornerstone not just for achieving success, but to proving it as well." So if software is not derived from scratch, having the traceability to know about its origination is invaluable. Given today's struggles, what is in store for the future software engineer? This paper is an attempt to quantify and answer (or at least project a possibility) that involves a new mindset and a new lifecycle model or structure change that may assist in tackling some of the above referenced issues. / text

As software becomes more important to society, the number, age, and complexity of systems grow. Software organizations require continuous process improvement to maintain the reliability, security, and quality of these software systems. Software organizations can utilize data from manual fault classification to meet their process improvement needs, but organizations lack the expertise or resources to implement them correctly. This dissertation addresses the need for the automation of software fault classification. Validation results show that automated fault classification, as implemented in the MiSFIT tool, can group faults of similar nature. The resulting classifications result in good agreement for common software faults with no manual effort. To evaluate the method and tool, I develop and apply an extended change taxonomy to classify the source code changes that repaired software faults from an open source project. MiSFIT clusters the faults based on the changes. I manually inspect a random sample of faults from each cluster to validate the results. The automatically classified faults are used to analyze the evolution of a software application over seven major releases. The contributions of this dissertation are an extended change taxonomy for software fault analysis, a method to cluster faults by the syntax of the repair, empirical evidence that fault distribution varies according to the purpose of the module, and the identification of project-specific trends from the analysis of the changes.

Many software systems eventually undergo changes to their basic architectural structure. Such changes may be prompted by new feature requests, new quality attribute requirements, changing technology, or other reasons. Whatever the causes, architecture evolution is commonplace in real-world software projects. Today’s software architects, however, have few techniques to help them plan such evolution. In particular, they have little assistance in planning alternatives, making trade-offs among these different alternatives, or applying best practices for particular domains. To address this, we have developed an approach for assisting architects in planning and reasoning about software architecture evolution. Our approach is based on modeling and analyzing potential evolution paths that represent different ways of evolving the system. We represent an evolution path as a sequence of transitional architectural states leading from the initial architecture to the target architecture, along with evolution operators that characterize the transitions among these states. We support analysis of evolution paths through the definition and application of constraints that express rules governing the evolution of the systemand evaluation functions that assess path quality. Finally, a set of these modeling elements may be grouped together into an evolution style that encapsulates a body of knowledge relevant to a particular domain of architecture evolution. We evaluate this approach in three ways. First, we evaluate its applicability to real-world architecture evolution projects. This is accomplished through case studies of two very different software organizations. Second, we undertake a formal evaluation of the computational complexity of verifying evolution constraints. Finally, we evaluate the implementability of the approach based on our experiences developing prototype tools for software architecture evolution.