By utilizing cloud infrastructures or platforms as services, SaaS providers can counter fluctuating loads through smoothly scaling up and down and therefore improve resource- and cost-efficiency, or transfer responsibility for the maintenance of complete underlying software stacks to a cloud provider, for instance. Our model-based approach CloudMIG aims at supporting SaaS providers to semi-automatically migrate legacy software systems to the cloud. Thereby, the analysis of conformance with the specific constraints imposed by a cloud environment candidate along with the detection of constraint violations constitutes an important early phase activity. We present an extensible architecture for describing cloud environments, their corresponding constraints, and appropriate violation detection mechanisms. There exist predefined constraint types with specified domain semantics as well as generic variants for modeling arbitrary constraints. A software system's compliance can be examined with the assistance of so called constraint validators. They operate on discovered KDM-based models of a legacy system. Additional constraint validators can be plugged into the validation process as needed. In this context, we implemented a prototype and modeled the PaaS environment Google App Engine for Java. We report on a quantitative evaluation regarding the detected constraint violations of five open source systems.

Software re-modularization is an old preoccupation of reverse engineering research. The advantages of a well structured or modularized system are well known. Yet after so much time and efforts, the field seems unable to come up with solutions that make a clear difference in practice. Recently, some researchers started to question whether some basic assumptions of the field were not overrated. The main one consists in evaluating the high-cohesion/low-coupling dogma with metrics of unknown relevance. In this paper, we study a real structuring case (on the Eclipse platform) to try to better understand if (some) existing metrics would have helped the software engineers in the task. Results show that the cohesion and coupling metrics used in the experiment did not behave as expected and would probably not have helped the maintainers reach there goal. We also measured another possible restructuring which is to decrease the number of cyclic dependencies between modules. Again, the results did not meet expectations.

This paper reports on a project to migrate PL/I programs running on an IBM mainframe under Z-OS to Java. The key point is that the transformation of the Code to Java was fully automated using the PLI2Java code transformation tool. The paper describes how the PL/I code was first reengineered to raise the quality and to put it into a form from which it could be converted over to an object - oriented architecture. It then goes on to define the process used to translate the code into Java. No less than 8 steps are required to make the transformation using static singleton objects with string data attributes and methods based on locality of reference. The Java components produced are object–oriented and data independent. In the end the results of the transformation are summarized and conclusions drawn for future work.