A modelagem evolutiva de bancos de dados é necessária devido às frequentes mudanças de requisitos das aplicações. O desafio é ainda maior quando o banco de dados tem de atender simultaneamente a várias aplicações. A solução proposta por Scott Ambler para evolução utiliza refatorações e define um período de transição, durante o qual tanto o esquema antigo quanto o novo coexistem e os dados são replicados por meio de um processo síncrono que apresenta várias dificuldades, como a interferência no funcionamento normal das aplicações. Para minimizar essas dificuldades, esta tese propõe um processo assíncrono para manter atualizados esses esquemas e apresenta um protótipo de uma ferramenta para auxiliar as evoluções dos bancos de dados. A proposta foi validada por meio de um experimento em laboratório que comparou a solução aqui apresentada com a proposta por Ambler. / Evolutionary database modeling is necessary due to the frequent changes in application requirements. The challenge is greater when the database must support multiple applications simultaneously. The solution for evolution proposed by Scott Ambler is refactoring with a transition period, during which both the old and the new database schemas coexist and data is replicated via a synchronous process, what brings several difficulties, such as interference with the normal operation of applications. To minimize these difficulties, this thesis proposes an asynchronous process to keep these schemas updated and presents a prototype tool to evolve databases. The proposal was validated by a laboratory experiment in which the solution presented here was compared with the one proposed by Ambler.

Um Data Warehouse (DW) é um banco de dados centralizado, orientado por assunto, integrado, não volátil e histórico, criado com o objetivo de dar apoio ao processo de tomada de decisão e que estrutura os dados em uma arquitetura analítica bastante distinta da arquitetura relacional utilizada nos bancos de dados transacionais. Construir um DW é um projeto de engenharia bastante complexo pois envolve muitas tecnologias e muitas pessoas, de diferentes equipes, em um grande esforço conjunto para construir esta base central de informações corporativas. O processo tradicional de construção de um DW não utiliza conceitos ágeis e, pelo escopo de desenvolvimento ser grande, pode levar muito tempo até que funcionalidades sejam entregues aos clientes. Os métodos ágeis de engenharia de software são muito usados como uma alternativa aos métodos tradicionais de desenvolvimento e têm diferenciais que trazem muito valor a projetos grandes pois, além de buscar desenvolver versões funcionais em prazos curtos, defendem que todos os sistemas têm a constante necessidade de se adaptar a mudanças. Neste trabalho são aplicadas práticas ágeis no processo tradicional de engenharia de DW para que o desenvolvimento seja realizado em ciclos iterativos curtos, tornando possível o desenvolvimento rápido e evolutivo de um DW com entregas constantes de novas funcionalidades. A contínua evolução deste complexo ambiente analítico é apoiada por conceitos de banco de dados evolutivos e também por fundamentos de métodos ágeis. / A data warehouse (DW) is a central database, subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management\'s decision making process and that summarize the data in an analytic architecture quite different from the relational one, used in transactional databases. Building a DW is a complex engineering project because it involves many technologies and many people, from different teams, in a huge corporative effort to build a central database with corporative data. The traditional engineering process to build a DW does not use agile concepts and, as its scope is quite big, it might takes a long time until the customer can use its features. Agile methods of software engineering are commonly used as an alternative to the traditional methods and they have some differentials that lead a lot of value to big projects, as the continuous attempt to develop short releases in short periods of time, or the belief that every system needs to be continuously adapted to the changes on its environment. This work applies agile practices in the traditional DW engineering method, so that the development can be done in short iterative cycles, making possible a fast and evolutive DW project, with frequent delivering of new functionalities. The continuous evolution of this complex analytical environment is supported by evolutive database concepts and also for agile methods foundations.

Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Evolution is a natural characteristic in software development. During the life cycle of a system, usually there is the need of evolution, mainly to add a new requirement, to change existing functionality, or to evolve the programming language used. The Fortran (FORmula TRANslation) language, despite having more than fifty years of existence, is still widely used in scientific applications. The majority of the existent Fortran applications is composed of legacy code, using obsolete or deprecated constructions of the language and, thus, need to evolve to improve their quality attributes. However, this process is often done manually, without the existence of well-defined rules to be followed, facilitating the introduction of anomalies in these applications. Software evolution can be benefited from refactoring, which provides well-defined mechanisms to be followed, helping to maintain and to improve the quality of existent systems. Refactoring is a software engineering technique that transforms software artefacts in order to improve them, without compromising their functionality. It is a permanent task in the life cycle of an application and is directly associated with the software non-functional requirements, such as modularization, legibility, and performance. This technique is widely used in objectoriented languages, but is still largely unexplored in procedural languages such as Fortran. In this context, this work explores the need for refactorings for the Fortran language, together with the issue of evolving legacy code. This goal is achieved through the proposal of a refactoring catalog to the evolution of Fortran programs, and the automation of some of them in the Photran framework. The proposed refactorings are evaluated and validated in applications written in Fortran. / A evolução é uma característica natural no desenvolvimento de software. Durante o ciclo de vida de um sistema, geralmente existe a necessidade de evolução, seja para a adição de um novo requisito, para a alteração de funcionalidades existentes, ou para a evolução da linguagem de programação usada. A linguagem Fortran (FORmula TRANslation), apesar de possuir mais de cinquenta anos de existência, ainda é amplamente usada em aplicações científicas. A maioria das aplicações Fortran existentes é composta de códigos legados, que usam construções obsoletas ou de uso desencorajado da linguagem, e normalmente precisam passar por uma evolução para melhorar seus atributos de qualidade. Porém, muitas vezes, esse processo é conduzido manualmente, sem a existência de regras bem definidas a serem seguidas, podendo ocorrer a introdução de anomalias nessas aplicações. A evolução de software pode ser auxiliada através de refatoração, que oferece mecanismos bem definidos a serem seguidos, ajudando a manter e melhorar a qualidade dos sistemas existentes. Refatoração é uma técnica de engenharia de software que efetua transformações em artefatos de software a fim de melhorá-los, sem comprometer suas funcionalidades. Trata-se de uma tarefa permanentemente presente no ciclo de vida de uma aplicação e está diretamente associada à requisitos não funcionais de software, tais como modularização, legibilidade e desempenho. Essa técnica é amplamente difundida para linguagens orientadas a objetos, mas é ainda pouco explorada em linguagens procedurais como Fortran. Nesse contexto, este trabalho explora a carência de refatorações para a linguagem Fortran, aliada à questão da evolução de código legado. Esse objetivo é alcançado através da proposta de um catálogo de refatorações para a evolução de programas Fortran, e da automação de algumas delas no framework Photran. As refatorações propostas são avaliadas e validadas em aplicações escritas em Fortran.

O Desenvolvimento de Software Orientado a Aspectos (AOSD) vem se consolidando como uma forma de resolver vários problemas das técnicas convencionais de programação, em particular em sistemas onde diversos interesses se encontram entrelaçados. A popularização dessa tecnologia faz surgir a necessidade de metodologias e ferramentas que facilitem o seu uso, como refatorações que levem em consideração suas características. No entanto as técnicas de modelagem de software disponíveis para AOSD não tem amadurecido no mesmo passo que as de implementação. Assim, para se poder pensar em mecanismos automáticos que trabalhem com a separação de interesses, é preciso verificar se as técnicas de modelagem existentes comportam isso. Este trabalho propõe uma adaptação da abordagem Theme de modelagem, para que ela permita uma representação mais fiel de sistemas que utilizam orientação a aspectos, em especial os que utilizam a linguagem AspectJ. Essa técnica proposta é utilizada para demonstrar algumas maneiras de detectar bad smells em sistemas orientados a aspectos. Também é mostrado como essa modelagem pode ser usada como base para a geração automática de código orientado a aspectos, e como pode ser feita a engenharia reversa de código existente de forma que ele possa ser analisado em forma de modelo. / Aspect‐Oriented Software Development (AOSD) is increasingly being considered a way to solve several problems in conventional programming methods, particularly in systems with crosscutting concerns. The popularization of this technology brings the need for methodologies and tools to ease its use, such as refactorings that take into account its characteristics. However modeling techniques available for AOSD are not maturing at the same rate as implementation techniques. Thus, in order to be able to devise automatic mechanisms that deal with separation of concerns, it is first necessary to verify if existing modeling techniques support that. In this work, we propose an adaptation of the Theme modeling approach, so that it represents aspect‐oriented systems more closely, especially those using the AspectJ language. This technique is used to demonstrate a few ways of detecting bad smells in aspect‐oriented systems. It is also shown how this model can be used as a basis for the automatic generation of aspectoriented code, and how existing code can be reverse‐engineered so that its model can be analyzed.

Sistemas de software bem modularizados podem trazer diversos benefícios como reu- sabilidade, compreensão, adaptabilidade, manutenibilidade, entre outros. O conceito de separação de interesses está diretamente ligado à ideia de modularização e consiste na capacidade de manter cada interesse em sua própria unidade modular. Um interesse pode estar relacionado tanto a requisitos funcionais como não-funcionais e em diferentes níveis de abstração. Algumas das técnicas que têm sido utilizadas para modularização de interes- ses são a Programação Orientada a Aspectos (POA) e Refatoração. Entretanto, a maioria das propostas de refatoração que envolvem a POA possui limitações para a modularização de interesses transversais: muitas delas são de granularidade fina; algumas são definidas imprecisamente e possuem sobreposição de intenções. A seleção e composição de tais refatorações para a modularização de interesses é uma tarefa difícil e não-trivial, além de variar em cada contexto específico, o que dificulta o reuso. Algumas das propostas de refatorações são voltadas especialmente para interesses transversais, no entanto possuem um nível de abstração pouco elevado e encontram-se acopladas a mecanismos específicos de linguagens de programação OO e OA. Adicionalmente, a aplicação de refatorações deve ser planejada e acompanhada sistematicamente durante o desenvolvimento e manu- tenção de um software, pois envolve alocação de recursos e avaliação de custo/benefício. O objetivo deste trabalho é apresentar um método de refatoração para modularização de interesses transversais, através de refatorações de granularidade alta, baseado em padrões recorrentes de estruturas transversais (chamados de sintomas). Além disso, como parte do método, propõem-se algoritmos para análise de impacto a fim de apoiar desenvolve- dores no processo decisório de aplicação de refatorações candidatas. Inicialmente, dois estudos bibliográficos foram conduzidos: o primeiro sobre propostas de refatorações que envolvem aspectos e o segundo sobre trabalhos de medição de interesses. Dois estudos de caso foram realizados totalizando 22 interesses de dois sistemas alvos. Este trabalho de avaliação possibilitou uma análise quantitativa e qualitativa dos resultados onde foi possível verificar a aplicabilidade do proposta. / Well-modularized software systems can bring several benefits such as reuse, com- prehension, adaptability, maintainability, among others. The concept of separation of concerns refers to the idea of modularisation, which consists on the ability to keep every concern in its own modular unit. A concern can refer to functional and non-functional requirements and can also be in different abstraction levels. Some of the techniques which have been applied for crosscutting concerns modularization are Aspect-Oriented Programming (AOP) and Refactoring. However, most of the aspect-oriented refactor- ings have limitations regarding the modularisation of crosscutting concerns. A number of them presents fine-grained transformations. While some of them are well-documented catalogues, a number of them are defined imprecisely, addressing the same situation and having overlapping intentions. They do not allow the designer to holistically reason about the elements involved in a crosscutting concern. It becomes difficult and non-trivial to choose a set of fine-grained refactorings and organize them in a feasible order to achieve the concern modularisation in a specific context. Some of the refactoring techniques are particularly focused on crosscutting concerns, however they are not placed in a suf- ficient abstraction level. Moreover they are coupled to specific OO and AO language mechanisms. Additionally, the application of refactorings should be planned and realized systematically during software development and maintenance since it involves resource allocation and tradeoff analysis. The goal of this work is to present a refactoring method for crosscutting concerns modularisation, through coarse-grained refactorings based on recurring patterns of crosscutting shapes (called symptoms). Also, as part of the method, algorithms for change-impact analysis are proposed in order to support developers during the decision process of the application of refactoring candidates. Initially, two biblio- graphic studies were made: the first one about refactoring approaches which involve as- pects, and the second one about concern measurement techniques. Two case studies were carried out totalizing 22 concerns of two target systems. This evaluation work allowed a quantitative and qualitative analysis of the results. Thus it was possible to verify the applicability of our approach.

Diversas refatorações têm sido propostas nos últimos anos para os mais variados paradigmas de programação, dentre eles o orientado a objetos e o orientado a aspecto. Seus impactos em atributos de qualidade são diversos, porém nem sempre a descrição original da refatoração apresenta todos os impactos que ela pode ter. Assim, é importante definir métodos de avaliação de refatorações para obter seus impactos em diferentes atributos de qualidade. A literatura apresenta trabalhos que utilizam métricas de software para fazer isso através de medições antes e depois de refatorar o código, porém este tipo de avaliação não permite obter conclusões válidas para todos os contextos em que a refatoração for aplicada. Outros trabalhos obtêm impactos abrangentes de refatorações orientadas a objetos, porém não foram encontrados métodos aplicáveis a refatorações orientadas a aspectos. Assim, este trabalho propõe uma forma de avaliar refatorações orientadas a aspectos para obter impactos abrangentes de sua aplicação, definindo um processo para avaliar refatorações orientadas a aspectos através do uso de métricas. Ele divide as etapas da refatoração em alterações pontuais e mede o impacto dessas alterações nos valores de um conjunto de métricas. O processo é usado para avaliar um conjunto de refatorações existentes na literatura definidas com o objetivo de extrair interesses transversais para aspectos. Para isso, são usados como critério de avaliação métricas para medir separação de interesses, tamanho, acoplamento e coesão do software. Como resultado, tem-se o impacto da refatoração em cada uma das métricas selecionadas, o que permite saber como o código será alterado antes mesmo de aplicar a refatoração. / Several software refactorings have been proposed on the last years for different programming paradigms, like object-oriented and aspect-oriented. They have several impacts on quality attributes, but their descriptions don’t describe all of these impacts, so it is important to have methods to assess refactorings to get their impacts on different quality attributes. Some papers apply software metrics on code before and after using the refactoring, but this kind os assessment avoids getting valid conclusions for all contexts where the refactoring can be used. Other papers propose assessment methods that get general conclusions for object-oriented refactorings, but no methods were found for assessing aspect-oriented refactorings. This work presents a process to assess aspect-oriented refactorings using software metrics to get their impacts on different quality attributes. It splits the refactoring steps into basic changes and measures the effects of these changes on some metrics. The process is used to assess some aspect-oriented refactorings for extracting crosscutting concerns into aspects, having as criteria software metrics to measure separation of concerns, size, coupling and cohesion. As result, we have the impact of the refactoring on each of the metric chosen, and know the consequences of the refactoring on the code before applying it.

The latest versions of AspectJ { the most popular aspect oriented extension for Java { must cope with complex changes that occurred in the Java type system, specially with the parametric polymorphism which aims to improve the type safety and the readability of the source code. However, for legacy and non-generic constructions to take advantage of this pervasive feature, they must be migrated to explicitly supply actual type parameters in both declarations and instantiations of generic classes. Even though the type systems of Java and AspectJ were designed to support this kind of migration in a gradual way, this process is somewhat complex and error prone. The reason behind this assertion is that actual type parameters must be inferred to remove as much unsafe downcasts as possible without a ecting the original semantics of the program. Therefore, tools are essential to minimize the e ort of a manual application of the refactoring steps and to prevent the introduction of new errors. Since current automated solutions focus only on Java programs, they do not consider the use of aspects to encapsulate crosscutting concerns. Thus, this dissertation proposes a novel collection of inference rules to derive type constraints for the polymorphic version of AspectJ. These rules were used together with an existing generic migration algorithm to enable the conversion of non-generic legacy code to add actual type parameters in both Java and AspectJ languages.

Many information systems that work with RDR (Relational Databases) have problems in the design of their databases. Such failures may result from design specification, requirement changes or even lack of knowledge to produce schemes that provide more evolutionary treatments for such systems. The technique that includes making changes to correct imperfections in databases that generate the mentioned problem is known as database refactoring. In order to identify possible opportunities for refactoring databases, this work proposes heuristics that detect or assist in detecting opportunities for refactoring. Thus, domain analysts and data professionals can identify the structure and data bad smells of a scheme and also take the necessary steps to address these shortcomings. / Muitos sistemas de informação que trabalham com BDR (Bancos de Dados Relacionais) apresentam problemas no projeto de suas bases de dados. Tais falhas podem ser decorrentes de falhas na construção, mudanças de requisitos ou falta de conhecimento por parte da equipe envolvida para produzir esquemas que proporcionem tratamentos mais evolutivos para tais sistemas. A técnica que possibilita fazer mudanças para corrigir imperfeições em bases de dados que geram os problemas citados é conhecida como refatoração (refactoring) em bases de dados. Objetivando identificar possíveis oportunidades de refatoração em bases de dados, este trabalho propõe heurísticas que detectam ou auxiliam na detecção de oportunidades de refatoração. Assim, analistas de domínio e profissionais da área de banco de dados poderão identificar, com maior agilidade, os defeitos compreendidos na estrutura e nos dados de um esquema e também tomar as providências necessárias para solucionar esses defeitos.

Diversas refatorações têm sido propostas nos últimos anos para os mais variados paradigmas de programação, dentre eles o orientado a objetos e o orientado a aspecto. Seus impactos em atributos de qualidade são diversos, porém nem sempre a descrição original da refatoração apresenta todos os impactos que ela pode ter. Assim, é importante definir métodos de avaliação de refatorações para obter seus impactos em diferentes atributos de qualidade. A literatura apresenta trabalhos que utilizam métricas de software para fazer isso através de medições antes e depois de refatorar o código, porém este tipo de avaliação não permite obter conclusões válidas para todos os contextos em que a refatoração for aplicada. Outros trabalhos obtêm impactos abrangentes de refatorações orientadas a objetos, porém não foram encontrados métodos aplicáveis a refatorações orientadas a aspectos. Assim, este trabalho propõe uma forma de avaliar refatorações orientadas a aspectos para obter impactos abrangentes de sua aplicação, definindo um processo para avaliar refatorações orientadas a aspectos através do uso de métricas. Ele divide as etapas da refatoração em alterações pontuais e mede o impacto dessas alterações nos valores de um conjunto de métricas. O processo é usado para avaliar um conjunto de refatorações existentes na literatura definidas com o objetivo de extrair interesses transversais para aspectos. Para isso, são usados como critério de avaliação métricas para medir separação de interesses, tamanho, acoplamento e coesão do software. Como resultado, tem-se o impacto da refatoração em cada uma das métricas selecionadas, o que permite saber como o código será alterado antes mesmo de aplicar a refatoração. / Several software refactorings have been proposed on the last years for different programming paradigms, like object-oriented and aspect-oriented. They have several impacts on quality attributes, but their descriptions don’t describe all of these impacts, so it is important to have methods to assess refactorings to get their impacts on different quality attributes. Some papers apply software metrics on code before and after using the refactoring, but this kind os assessment avoids getting valid conclusions for all contexts where the refactoring can be used. Other papers propose assessment methods that get general conclusions for object-oriented refactorings, but no methods were found for assessing aspect-oriented refactorings. This work presents a process to assess aspect-oriented refactorings using software metrics to get their impacts on different quality attributes. It splits the refactoring steps into basic changes and measures the effects of these changes on some metrics. The process is used to assess some aspect-oriented refactorings for extracting crosscutting concerns into aspects, having as criteria software metrics to measure separation of concerns, size, coupling and cohesion. As result, we have the impact of the refactoring on each of the metric chosen, and know the consequences of the refactoring on the code before applying it.

The latest versions of AspectJ { the most popular aspect oriented extension for Java { must cope with complex changes that occurred in the Java type system, specially with the parametric polymorphism which aims to improve the type safety and the readability of the source code. However, for legacy and non-generic constructions to take advantage of this pervasive feature, they must be migrated to explicitly supply actual type parameters in both declarations and instantiations of generic classes. Even though the type systems of Java and AspectJ were designed to support this kind of migration in a gradual way, this process is somewhat complex and error prone. The reason behind this assertion is that actual type parameters must be inferred to remove as much unsafe downcasts as possible without a ecting the original semantics of the program. Therefore, tools are essential to minimize the e ort of a manual application of the refactoring steps and to prevent the introduction of new errors. Since current automated solutions focus only on Java programs, they do not consider the use of aspects to encapsulate crosscutting concerns. Thus, this dissertation proposes a novel collection of inference rules to derive type constraints for the polymorphic version of AspectJ. These rules were used together with an existing generic migration algorithm to enable the conversion of non-generic legacy code to add actual type parameters in both Java and AspectJ languages.