Software Engineering and Architecture Group (SEARCH) > CS > JBI > FWN > RUG

Architecture Recovery from DevOps Artifacts (multiple theses available)

Understanding and updating the architecture of a software system is critical for any maintenance tasks to it [Garcia et al. 2013]. Architecture recovery from system implementation is an ongoing challenge, with many automated techniques developed over the last years. Surveys like [Garcia et al. 2013] and [Lutellier et al. 2015] provide a good overview of the state of the art in the field. Architecture recovery has the potential to be especially useful in environments where a DevOps-oriented software development culture is in effect. DevOps is defined as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality” [Bass et al. 2015]. As such, DevOps practices and technologies eschew the use of top-down, model-driven software engineering approaches for more agile continuous delivery techniques, e.g. through micro-services. In many cases, the overall architecture of the software system remains largely undocumented, and manifests only through the dependencies between software artifacts during system deployment.

This work aims to apply architecture recovery techniques to publicly available, and in many cases crowd-sourced DevOps artifact collections as the means to understand the system architecture that these artifacts implicit depend on. Since most existing techniques rely on line of code analysis, which is not applicable in many cases for the available artifacts, they will need to be adapted accordingly to e.g. identify dependencies between components through their deployment scripts. Multiple theses are available in parallel, assuming that they do not overlap on the DevOps technology that they focus on.

Objective & Tasks:
The overall goal of this thesis is to design, implement, and evaluate a scalable, modular, and extensible architecture recovery system that accepts a set of related DevOps artifacts as an input, and produces one or more system architecture models that fit the provided input. A domain agnostic language like GENTL [Andrikopoulos et al. 2013] can be used for the modeling of the recovered architectures.

The following tasks are envisioned:

  • Survey and establish the State of the Art in architecture recovery
  • Selection and familiarization with one or more DevOps technologies
  • Design, development, and testing of an architecture recovery tool from publicly available artifacts in the selected DevOps technologies
  • Evaluation of the tool through a case study

The student is expected to be familiar, or willing to quickly become familiar with:

  • One or more DevOps tools (Chef, Puppet, Jenkins, Vagrant, etc.), or toolkits and services offered by specific providers/software solutions (AWS, Openstack Heat, etc.)
  • A high-level programming language (Java is preferred, but not necessary)
  • Existing architecture recovery techniques as discussed in the literature

If you are interested in this project or have any questions, please do not hesitate to contact: Vasilios Andrikopoulos (

Andrikopoulos, Vasilios, Anja Reuter, Santiago Gómez Sáez, and Frank Leymann. "A GENTL approach for cloud application topologies." In Proceedings of the European Conference on Service-Oriented and Cloud Computing, pp. 148-159. Springer Berlin Heidelberg, 2014.

Bass, Len, Ingo Weber, and Liming Zhu. DevOps: A Software Architect's Perspective. Addison-Wesley Professional, 2015.

Garcia, Joshua, Igor Ivkovic, and Nenad Medvidovic. "A comparative analysis of software architecture recovery techniques." In Automated Software Engineering (ASE), 2013 IEEE/ACM 28th International Conference on, pp. 486-496. IEEE, 2013.

Lutellier, Thibaud, Devin Chollak, Joshua Garcia, Lin Tan, Derek Rayside, Nenad Medvidovic, and Robert Kroeger. "Comparing software architecture recovery techniques using accurate dependencies." In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2, pp. 69-78. IEEE, 2015.