Refactoring in der Ontologiegetriebenen Softwareentwicklung

In der vorliegenden Arbeit wird ein Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme erarbeitet. Ontologiegetriebene Softwaresysteme sind Softwaresysteme, bei denen Ontologien als zentrale Designdokumente zum Einsatz kommen. Ontologien sind gleichzeitig zentrale Bestandteile des ausführbaren Systems und dienen zur Strukturbeschreibung und Datenhaltung. Dabei werden Teile des Softwaresystems automatisch aus den Strukturbeschreibungen der Ontologie abgeleitet. Diese Arbeit konzentriert sich auf die Weiterentwicklung solcher Systeme und stellt dafür einen Katalog von Ontologie-Refactorings auf. Es werden mehrere Werkzeuge, gemeinsam als OntoMore bezeichnet, implementiert, um die Umsetzbarkeit des aufgestellten Konzepts zu zeigen. OntoMore kann Ontologien in Metamodelle und Modelle des EMF umwandeln und somit in Softwaresysteme integrieren. Außerdem ist es in der Lage, Refactorings auf beiden Strukturen synchron auszuführen. Dieser Prozess wird als Co-Refactoring bezeichnet. Damit wird die konsistente Evolution von Ontologien und Modellen sichergestellt. Die Implementierung wird anhand einer Beispiel-Ontologie zum Freelancer-Management evaluiert.:1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Grundlagen 5 2.1 Modellgetriebene Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Ontologien und semantische Techniken 11 3.1 Grundlagen semantischer Techniken . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1 Definition und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 Die Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . . . 14 3.2.3 Ontologie-Syntaxen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Beschreibungslogiken, Teilsprachen und Profile . . . . . . . . . . . . . 18 3.2.5 Abfragen mit SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.6 Beispiele für Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Ontologie-Evolution und Versionierung . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Unterschiede zwischen Ontologie-Evolution und Refactoring . . . . . . . . . . . 23 3.5 Zukünftige Entwicklungen – Linked Data . . . . . . . . . . . . . . . . . . . . . 24 3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Eingesetzte Werkzeuge 27 4.1 Verbindung von Ontologien und Modellen mit OntoMoPP . . . . . . . . . . . 27 4.2 Generisches Modell-Refactoring mit Refactory . . . . . . . . . . . . . . . . . . 28 5 Stand der Forschung 31 5.1 Abbildung von Ontologien auf Domänenmodelle . . . . . . . . . . . . . . . . . 31 5.1.1 Einsatz von Ontologien in der Modellierung . . . . . . . . . . . . . . . 31 5.1.2 Abbildungen zwischen Ontologien und Datenbanken . . . . . . . . . . . 35 5.2 Ontologie-Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1 Anforderungen an Ontologie-Evolution . . . . . . . . . . . . . . . . . . 37 5.2.2 Elementare und komplexe Änderungsoperationen . . . . . . . . . . . . 38 5.2.3 KAON – Das Karlsruhe Ontology and Semantic Web Framework . . . . 38 5.2.4 Das NeOn-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.5 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.6 Bewertung vorhandener Systeme zur Ontologie-Evolution . . . . . . . . 47 5.3 Co-Evolution von Metamodellen und Modellen . . . . . . . . . . . . . . . . . . 48 5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6 Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme 51 6.1 Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 OWL-Ecore-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3 Refactorings für OWL und Ecore . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3.1 Definition und Katalog von Ontologie-Refactorings . . . . . . . . . . . 62 6.3.2 Schema eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 63 6.3.3 Beispiel eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 66 6.4 Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.1 Definition und Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.2 Herleitung und Architekturvergleich . . . . . . . . . . . . . . . . . . . 70 6.4.3 Der CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7 Praktische Umsetzung 75 7.1 Architektur und eingesetzte Techniken . . . . . . . . . . . . . . . . . . . . . . 75 7.2 Testgetriebene Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3 OWL-Ecore-Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4 Refactoring mit Refactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.5 CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8 Evaluation 91 8.1 Die Beispiel-Ontologie: FrOnto . . . . . . . . . . . . . . . . . . . . . . . . . . 91 8.2 Bewertung der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.3 Grenzen der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4 Grenzen der Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9 Zusammenfassung 101 9.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.1 Das Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.2 Beziehung zwischen Ontologien und Domänenmodellen . . . . . . . . . 101 9.1.3 Konzeption von Refactorings und Co-Refactorings . . . . . . . . . . . . 102 9.1.4 Implementierung von OntoMore . . . . . . . . . . . . . . . . . . . . . 103 9.1.5 Evaluation anhand einer Beispiel-Ontologie . . . . . . . . . . . . . . . 103 9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Anhang i A Weitere Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . . i B Auswirkungen von Ontologie-Refactorings bezüglich der Datenmigration . . . . . . i C Die MiniFrOnto vor und nach dem Refactoring . . . . . . . . . . . . . . . . . . . iii D Refactoring mit der OWL-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . v Abbildungsverzeichnis vii Tabellenverzeichnis ix Listings xi Abkürzungsverzeichnis xiii Literaturverzeichnis xvIn this thesis an approach is elaborated for the development and evolution of ontology-driven software systems. Ontology-driven software systems are software systems for which ontologies serve as main design documents. Ontologies are furthermore central parts of the running system. They describe the structure of the system and hold data. Parts of the software system are automatically derived from the structure descriptions of the ontology. This work concentrates on the evolution of those systems, thereby defining a catalogue of ontology refactorings. A tool suite called OntoMore is implemented to show the feasibility of the elaborated approach. OntoMore can transform ontologies in metamodels and models of EMF to integrate them in software systems. It can furthermore execute refactorings synchronously on both structures, which is called Co-Refactoring. Hence the consistent evolution of ontologies and models is ensured. The implementation is evaluated with an example ontology about the freelancer domain.:1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Grundlagen 5 2.1 Modellgetriebene Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Ontologien und semantische Techniken 11 3.1 Grundlagen semantischer Techniken . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1 Definition und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 Die Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . . . 14 3.2.3 Ontologie-Syntaxen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Beschreibungslogiken, Teilsprachen und Profile . . . . . . . . . . . . . 18 3.2.5 Abfragen mit SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.6 Beispiele für Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Ontologie-Evolution und Versionierung . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Unterschiede zwischen Ontologie-Evolution und Refactoring . . . . . . . . . . . 23 3.5 Zukünftige Entwicklungen – Linked Data . . . . . . . . . . . . . . . . . . . . . 24 3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Eingesetzte Werkzeuge 27 4.1 Verbindung von Ontologien und Modellen mit OntoMoPP . . . . . . . . . . . 27 4.2 Generisches Modell-Refactoring mit Refactory . . . . . . . . . . . . . . . . . . 28 5 Stand der Forschung 31 5.1 Abbildung von Ontologien auf Domänenmodelle . . . . . . . . . . . . . . . . . 31 5.1.1 Einsatz von Ontologien in der Modellierung . . . . . . . . . . . . . . . 31 5.1.2 Abbildungen zwischen Ontologien und Datenbanken . . . . . . . . . . . 35 5.2 Ontologie-Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1 Anforderungen an Ontologie-Evolution . . . . . . . . . . . . . . . . . . 37 5.2.2 Elementare und komplexe Änderungsoperationen . . . . . . . . . . . . 38 5.2.3 KAON – Das Karlsruhe Ontology and Semantic Web Framework . . . . 38 5.2.4 Das NeOn-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.5 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.6 Bewertung vorhandener Systeme zur Ontologie-Evolution . . . . . . . . 47 5.3 Co-Evolution von Metamodellen und Modellen . . . . . . . . . . . . . . . . . . 48 5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6 Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme 51 6.1 Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 OWL-Ecore-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3 Refactorings für OWL und Ecore . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3.1 Definition und Katalog von Ontologie-Refactorings . . . . . . . . . . . 62 6.3.2 Schema eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 63 6.3.3 Beispiel eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 66 6.4 Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.1 Definition und Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.2 Herleitung und Architekturvergleich . . . . . . . . . . . . . . . . . . . 70 6.4.3 Der CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7 Praktische Umsetzung 75 7.1 Architektur und eingesetzte Techniken . . . . . . . . . . . . . . . . . . . . . . 75 7.2 Testgetriebene Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3 OWL-Ecore-Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4 Refactoring mit Refactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.5 CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8 Evaluation 91 8.1 Die Beispiel-Ontologie: FrOnto . . . . . . . . . . . . . . . . . . . . . . . . . . 91 8.2 Bewertung der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.3 Grenzen der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4 Grenzen der Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9 Zusammenfassung 101 9.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.1 Das Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.2 Beziehung zwischen Ontologien und Domänenmodellen . . . . . . . . . 101 9.1.3 Konzeption von Refactorings und Co-Refactorings . . . . . . . . . . . . 102 9.1.4 Implementierung von OntoMore . . . . . . . . . . . . . . . . . . . . . 103 9.1.5 Evaluation anhand einer Beispiel-Ontologie . . . . . . . . . . . . . . . 103 9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Anhang i A Weitere Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . . i B Auswirkungen von Ontologie-Refactorings bezüglich der Datenmigration . . . . . . i C Die MiniFrOnto vor und nach dem Refactoring . . . . . . . . . . . . . . . . . . . iii D Refactoring mit der OWL-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . v Abbildungsverzeichnis vii Tabellenverzeichnis ix Listings xi Abkürzungsverzeichnis xiii Literaturverzeichnis x

Migration of Applications across Object-Oriented APIs

Software developers often encapsulate reusable code as Application Programming Interfaces (APIs). The co-evolution of applications and APIs may motivate an API migration: the replacement of application dependencies to an original API by dependencies to an alternative API that provides similar functionality and abstractions. In this dissertation, we investigate issues associated with API migration in object-oriented systems, with special focus on wrapping approaches. We present two studies and a set of developer interviews that elicit issues in the process and techniques used in API migration in practice. The results suggest that the most pressing issues relate to discovery and specification of differences between APIs, and to assessment of migration correctness. This dissertation introduces techniques and a method to address these issues. We propose the use of design patterns to support the specification of API wrappers. API wrapping design patterns encode solutions to common wrapping design problems. We present an initial catalog of such patterns that were abstracted from programming idioms found in existing API wrappers. We introduce the concept of compliance testing for API migration, a form of automated testing. Compliance testing supports the discovery of behavioral differences between a wrapper and its corresponding original API, as well as assessment of wrapper correctness. Compliance testing uses API contracts and assertion tunings to explicitly capture and enforce the notion of a “good enough” wrapper that is informal in practice. We present the Koloo method for wrapper-based API migration. The method prescribes practical steps to use compliance testing as a means to elicit the requirements for the API migration, and to assess its correctness. Koloo fits within the iterative, sample-driven general API migration process usually followed by developers in practice. We evaluate the Koloo method in an empirical study. The subjects cover the domains of XML processing, GUI programming and bytecode engineering. The results provide evidence that Koloo is superior to alternative methods in driving the development of a wrapper that is tailored for the application under migration. The results also show that API contracts help driving the evolution of the wrapper, and assertion tuning is necessary to relax the semantics of strict equality contracts, and useful to compromise on features that are difficult to emulate perfectly. Finally, we validate that the proposed design patterns are used in practical wrappers

Designing Round-Trip Systems by Change Propagation and Model Partitioning

Software development processes incorporate a variety of different artifacts (e.g., source code, models, and documentation). For multiple reasons the data that is contained in these artifacts does expose some degree of redundancy. Ensuring global consistency across artifacts during all stages in the development of software systems is required, because inconsistent artifacts can yield to failures. Ensuring consistency can be either achieved by reducing the amount of redundancy or by synchronizing the information that is shared across multiple artifacts. The discipline of software engineering that addresses these problems is called Round-Trip Engineering (RTE). In this thesis we present a conceptual framework for the design RTE systems. This framework delivers precise definitions for essential terms in the context of RTE and a process that can be used to address new RTE applications. The main idea of the framework is to partition models into parts that require synchronization - skeletons - and parts that do not - clothings. Once such a partitioning is obtained, the relations between the elements of the skeletons determine whether a deterministic RTE system can be built. If not, manual decisions may be required by developers. Based on this conceptual framework, two concrete approaches to RTE are presented. The first one - Backpropagation-based RTE - employs change translation, traceability and synchronization fitness functions to allow for synchronization of artifacts that are connected by non-injective transformations. The second approach - Role-based Tool Integration - provides means to avoid redundancy. To do so, a novel tool design method that relies on role modeling is presented. Tool integration is then performed by the creation of role bindings between role models. In addition to the two concrete approaches to RTE, which form the main contributions of the thesis, we investigate the creation of bridges between technical spaces. We consider these bridges as an essential prerequisite for performing logical synchronization between artifacts. Also, the feasibility of semantic web technologies is a subject of the thesis, because the specification of synchronization rules was identified as a blocking factor during our problem analysis. The thesis is complemented by an evaluation of all presented RTE approaches in different scenarios. Based on this evaluation, the strengths and weaknesses of the approaches are identified. Also, the practical feasibility of our approaches is confirmed w.r.t. the presented RTE applications

On Preserving the Behavior in Software Refactoring: A Systematic Mapping Study

Context: Refactoring is the art of modifying the design of a system without altering its behavior. The idea is to reorganize variables, classes and methods to facilitate their future adaptations and comprehension. As the concept of behavior preservation is fundamental for refactoring, several studies, using formal verification, language transformation and dynamic analysis, have been proposed to monitor the execution of refactoring operations and their impact on the program semantics. However, there is no existing study that examines the available behavior preservation strategies for each refactoring operation. Objective: This paper identifies behavior preservation approaches in the research literature. Method: We conduct, in this paper, a systematic mapping study, to capture all existing behavior preservation approaches that we classify based on several criteria including their methodology, applicability, and their degree of automation. Results: The results indicate that several behavior preservation approaches have been proposed in the literature. The approaches vary between using formalisms and techniques, developing automatic refactoring safety tools, and performing a manual analysis of the source code. Conclusion: Our taxonomy reveals that there exist some types of refactoring operations whose behavior preservation is under-researched. Our classification also indicates that several possible strategies can be combined to better detect any violation of the program semantics

On Language Processors and Software Maintenance

This work investigates declarative transformation tools in the context of software maintenance. Besides maintenance of the language specification, evolution of a software language requires the adaptation of the software written in that language as well as the adaptation of the software that transforms software written in the evolving language. This co-evolution is studied to derive automatic adaptations of artefacts from adaptations of the language specification. Furthermore, AOP for Prolog is introduced to improve maintainability of language specifications and derived tools.Die Arbeit unterstützt deklarative Transformationswerkzeuge im Kontext der Softwarewartung. Neben der Wartung der Sprachbeschreibung erfordert die Evolution einer Sprache sowohl die Anpassung der Software, die in dieser Sprache geschrieben ist als auch die Anpassung der Software, die diese Software transformiert. Diese Koevolution wird untersucht, um automatische Anpassungen von Artefakten von Anpassungen der Sprachbeschreibungen abzuleiten. Weiterhin wird AOP für Prolog eingeführt, um die Wartbarkeit von Sprachbeschreibungen und den daraus abgeleiteten Werkzeugen zu erhöhen

Refactoring de bases de datos : Desarrollo evolutivo de bases de bases de datos integrado con MDD

Cada vez es más frecuente que los requerimientos cambien a medida que un proyecto de software progresa. Al mismo tiempo el cliente demanda resultados rápidos, que puedan implementarse y medirse en períodos cortos de tiempo. Es por ello que en los últimos tiempos, han ganando mucho terreno los procesos de software, también llamados metodologías, de naturaleza evolutivos y ágiles, cuyas principales premisas son el trabajo altamente colaborativo, iterativo e incremental. Para esto los programadores adoptaron técnicas como TDD (Test Driven Development, Desarrollo Dirigido por Tests) y AMDD (Agile Model Driven Development, Desarrollo Ágil Dirigido por Modelos), y se construyeron herramientas que facilitaron la aplicación de las mismas. Pero no ocurrió lo mismo en la comunidad de profesionales de bases de datos. Se podrían encontrar principalmente dos razones que explican esto: 1. Impedimentos culturales: Muchos de los actuales profesionales del área de datos se formaron durante los años 70 y 80, perdiendo la revolución de los objetos en los años 90 y la experiencia ganada en el desarrollo evolutivo. 2. Curva de aprendizaje: Lleva tiempo aprender nuevas técnicas, más aún si es necesario un cambio de mentalidad que permita pasar de procesos seriales o en cascada a evolutivos. En 1999 Martin Fowler propuso la técnica de programación de refactoring en su libro [FO 99]. Un refactoring es un pequeño cambio en el código fuente que mejora el diseño sin cambiar su semántica. En otras palabras, se mejora la calidad del código sin cambiar ni añadir ningún comportamiento. Refactoring permite evolucionar el código lentamente con el tiempo, para tomar un enfoque evolutivo (iterativo e incremental) de programación. En su libro, Fowler discute la idea de que de la misma manera que es posible aplicar un refactoring en el código fuente de la aplicación, es también posible aplicar un refactoring en el esquema de la base de datos. Sin embargo, aplicar un refactoring en la base de datos es algo más complejo por los significativos niveles de acoplamiento asociados a los datos. Actualmente se necesita profundizar las técnicas y herramientas que también soporten el desarrollo evolutivo para las bases de datos; y en nuestra opinión la más importante de estas técnicas es el refactoring de base de datos. En [AS 06] se presenta un marco teórico de cómo puede llevarse a cabo un esquema de trabajo evolutivo sobre las bases de datos. La premisa principal consiste en realizar los cambios sobre el modelo garantizando durante un período determinado (lo cual llamamos período de transición) la coexistencia entre ambas versiones de la base de datos. De esta forma, las aplicaciones que usen la base de datos seguirán funcionando sin la necesidad de adaptarse inmediatamente a la nueva versión de la base datos. De este modo, principal motivación consiste entonces en poder brindar una herramienta que automatice las tareas de refactoring de base de datos según los lineamientos establecidos en [AS 06].Facultad de Informátic