Add information on migration types

Author: florian-beetz

bibliography/references.bib

@@ -91,6 +91,21 @@ @InProceedings{Cartwright1998
   groups    = {Software Migration, Java},
 }
 
+@InProceedings{Kontogiannis1998,
+  author    = {Kostas Kontogiannis and Johannes Martin and Kenny Wong and Richard Gregory and Hausi A. M{\"{u}}ller and John Mylopoulos},
+  title     = {Code migration through transformations: an experience report},
+  booktitle = {Proceedings of the 1998 conference of the Centre for Advanced Studies on Collaborative Research, November 30 - December 3, 1998, Toronto, Ontario, Canada},
+  year      = {1998},
+  editor    = {Stephen A. MacKay and J. Howard Johnson},
+  publisher = {{IBM}},
+  pages     = {13},
+  doi       = {10.1145/783160.783173},
+  bibsource = {dblp computer science bibliography, https://dblp.org},
+  biburl    = {https://dblp.org/rec/bib/conf/cascon/KontogiannisMWGMM98},
+  file      = {:10.1.1.50.4373.pdf:PDF},
+  groups    = {Software Migration},
+}
+
 @Article{Olsem1998,
   author   = {Michael R. Olsem},
   title    = {An incremental approach to software systems re-engineering},
@@ -122,6 +137,21 @@ @Article{Bisbal1999
   groups    = {Software Migration},
 }
 
+@Article{Terekhov2000,
+  author    = {Andrey A. Terekhov and Chris Verhoef},
+  title     = {The Realities of Language Conversions},
+  journal   = {{IEEE} Software},
+  year      = {2000},
+  volume    = {17},
+  number    = {6},
+  pages     = {111--124},
+  doi       = {10.1109/52.895180},
+  bibsource = {dblp computer science bibliography, https://dblp.org},
+  biburl    = {https://dblp.org/rec/bib/journals/software/TerekhovV00},
+  file      = {:Terekhov2000 - The Realities of Language Conversions.pdf:PDF},
+  groups    = {Software Migration},
+}
+
 @Article{Chapin2001,
   author    = {Ned Chapin and Joanne E. Hale and Khaled Md. Khan and Juan F. Ramil and Wui{-}Gee Tan},
   title     = {Types of software evolution and software maintenance},
@@ -214,6 +244,38 @@ @Online{Meier2007
   url    = {http://spin.sourceforge.net/solution.html},
 }
 
+@InProceedings{Bartolomei2009,
+  author    = {Thiago Tonelli Bartolomei and Krzysztof Czarnecki and Ralf L{\"{a}}mmel and Tijs van der Storm},
+  title     = {Study of an {API} Migration for Two {XML} APIs},
+  booktitle = {Software Language Engineering, Second International Conference, {SLE} 2009, Denver, CO, USA, October 5-6, 2009, Revised Selected Papers},
+  year      = {2009},
+  editor    = {Mark van den Brand and Dragan Gasevic and Jeff Gray},
+  volume    = {5969},
+  series    = {Lecture Notes in Computer Science},
+  publisher = {Springer},
+  pages     = {42--61},
+  doi       = {10.1007/978-3-642-12107-4\_5},
+  url       = {https://doi.org/10.1007/978-3-642-12107-4\_5},
+  bibsource = {dblp computer science bibliography, https://dblp.org},
+  biburl    = {https://dblp.org/rec/bib/conf/sle/BartolomeiCLS09},
+  file      = {:Bartolomei2009 - Study of an API Migration for Two XML APIs.pdf:PDF},
+  groups    = {Software Migration},
+}
+
+@InProceedings{Bartolomei2010,
+  author    = {Thiago Tonelli Bartolomei and Krzysztof Czarnecki and Ralf L{\"{a}}mmel},
+  title     = {Swing to {SWT} and back: Patterns for {API} migration by wrapping},
+  booktitle = {26th {IEEE} International Conference on Software Maintenance {(ICSM} 2010), September 12-18, 2010, Timisoara, Romania},
+  year      = {2010},
+  publisher = {{IEEE} Computer Society},
+  pages     = {1--10},
+  doi       = {10.1109/ICSM.2010.5610429},
+  bibsource = {dblp computer science bibliography, https://dblp.org},
+  biburl    = {https://dblp.org/rec/bib/conf/icsm/TonelliKR10},
+  file      = {:Bartolomei2010 - Swing to SWT and Back_ Patterns for API Migration by Wrapping.pdf:PDF},
+  groups    = {Software Migration},
+}
+
 @Article{Hall2011,
   author  = {Hall, Richard S and Pauls, Karl and McCulloch, Stuart and Savage, David},
   title   = {OSGi in action},
@@ -284,6 +346,21 @@ @Online{JabRefDevelopers2015
   groups = {JabRef},
 }
 
+@InProceedings{Hora2015,
+  author    = {Andr{\'{e}} C. Hora and Marco Tulio Valente},
+  title     = {Apiwave: Keeping track of {API} popularity and migration},
+  booktitle = {2015 {IEEE} International Conference on Software Maintenance and Evolution, {ICSME} 2015, Bremen, Germany, September 29 - October 1, 2015},
+  year      = {2015},
+  editor    = {Rainer Koschke and Jens Krinke and Martin P. Robillard},
+  publisher = {{IEEE} Computer Society},
+  pages     = {321--323},
+  doi       = {10.1109/ICSM.2015.7332478},
+  bibsource = {dblp computer science bibliography, https://dblp.org},
+  biburl    = {https://dblp.org/rec/bib/conf/icsm/HoraV15},
+  file      = {:Hora2015 - Apiwave_ Keeping Track of API Popularity and Migration.pdf:PDF},
+  groups    = {Software Migration},
+}
+
 @WWW{Marx2016,
   author = {Dustin Marx},
   editor = {Inspired by Actual Events},
@@ -596,6 +673,22 @@ @Online{OracleDocJavac
   groups = {Java},
 }
 
+@Online{GHCM,
+  author  = {{Glasgow Haskell Compiler Maintainers}},
+  title   = {GHC 8.4.x Migration Guide},
+  url     = {https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4},
+  urldate = {2018-08-09},
+}
+
+@Online{Miller,
+  author  = {Heather Miller},
+  editor  = {{Scala}},
+  title   = {{M}igrating from {S}cala 2.7},
+  url     = {https://docs.scala-lang.org/overviews/collections/migrating-from-scala-27.html},
+  urldate = {2018-08-09},
+  groups  = {Software Migration},
+}
+
 @Comment{jabref-meta: databaseType:biblatex;}
 
 @Comment{jabref-meta: fileDirectory:sources;}

bibliography/sources/Bartolomei2009 - Study of an API Migration for Two XML APIs.pdf

@@ -102,6 +102,11 @@ Software migration tasks can be grouped into three general classes:
   compatible, even when new features were added, in large code bases, however,
   additional effort is required to use new versions of compilers.
 
+  Not much literature exists on the topic of this type of migration.
+  Often when a new version of a compiler introduces incompatibilities with
+  previous versions, a migration guide is issued by the compiler maintainers
+  [@Miller; @GHCM].
+
 * **+API migration** is the process of changing a dependency on an external
   +API to another one or a different version [@Malton2001].
 
@@ -120,12 +125,45 @@ Software migration tasks can be grouped into three general classes:
   services offered by an +API, but not for public consumption [@Dig2006].
   Many languages do not provide features to explicitly mark such elements as
   internal, but library authors rely solely on naming conventions, e.g. placing
-  code in an `internal` namespace. 
+  code in an `internal` namespace.
+
+  In [@Bartolomei2009] Bartolomei et al. identify two general approaches for
+  API migrations:
+  When a source +API should be replaced with a target +API, either all usages of
+  the source +API can be directly replaced with corresponding calls to the
+  target +API, or a wrapper around the target +API can be created with the
+  interface of the source +API.
+  They note that the difficulty of an +API migration greatly depends on the
+  differences both ++API have.
+  Hora and Valente propose a tool that tracks what ++API open source projects
+  use and when and to which ++API they migrate in [@Hora2015].
+  This aims at supporting software engineers finding replacement ++API.
 
 * **Language migration** is the decision to convert an existing program to a new
   language [@Malton2001]. This is a risky type of migration, as it requires much
   effort to re-express source code in a different language.
 
+  This type of migration is well studied:
+  Kontogiannis et al. perform a migration of a system written in PL/IX to C++ in
+  [@Kontogiannis1998]. 
+  They find that a problem is simulating language constructs of the source
+  language that is not available in the target language.
+  Terekhov and Verhoef argue in [@Terekhov2000] that too much effort is put
+  on automatic tooling aiding in the conversion, but instead the focus should
+  lay on the software engineers performing the migration.
+  Martin and Müller present their approach for migrating C programs to Java in
+  [@Martin2002].
+  They use an automatic tool to perform the migration and find that often,
+  manual adjustments are required to obtain readable code in the target
+  language.   
+
+For this thesis mostly the groups of dialect migration and +API migration are
+relevant.
+The language Java will be kept, but only updated to a new version.
+This mostly corresponds to a dialect conversion.
+However, as will be described later, the ++API available in the Java language
+also have changed at some parts, so also an +API migration is relevant.
+
 The general approach for adaptive software maintenance consists of a sequence of
 steps as shown in [@fig:adaptive_maintenance].