Software Reengineering

Serge Demeyer
Assistants: Dr. Henrique Rocha, Dr. John Businge


Who ?

  • Master Computer Science Period: 2nd semester 2020-2021

Where ? When ?

  • Theory & Exercises all during the same time slot
  • Time: Wed 13:45 - 18:00
    • Sometimes on other days; check the schedule below
  • Location: Fully virtual. Lectures will stream via blackboard, Q&A sessions will be handled via teams

Course Content

This course explains the 'state-of-the-art' reengineering existing software systems. This includes an introduction to the recent research, as well as an overview of the principles techniques and skills applied in practice today. Students will acquire a range of principles, techniques, and skills that are currently being used for reengineering existing software systems. Consequently, the course has a practical ring to it with a minimal theoretical content (taught as reengineering patterns), several lab-sessions (experimenting with a suite of reengineering tools) and one project (restructuring an existing large software system).

Objectives (expected learning outcomes)

To goal of this course is to become acquainted with a broad selection of principles, techniques and skills used when reengineering existing software systems. After this course, a student will be able to:

  • assess which parts should be reengineered first;
  • identify the risks and opportunities for a given re-engineering project;
  • extract coarse-grained and fine-grained design models;
  • exploit tests during re-engineering;
  • select the most appropriate migration strategy;
  • solve the typical problems of an object-oriented re-engineering project.

Time schedule

To realize these objectives, the course is organized as follows. We start with an introductory class outlining the state of the art in re-engineering and proceed with a couple of lab sessions (marked with [L] in the detailed time-schedule), in which several reverse and re-engineering tools will be tested under lab conditions. Afterward, students will experiment with these tools and the associated techniques in realistic circumstances by means of a Project, which will also serve as the main outcome.


  • Announce Project: At the outset of the project, students should announce which software system they intend to reengineer (yes, you can propose one yourself) and whether they intend to do so individually or in groups (duo projects are encouraged).
  • Precondition Report - Project Setup. When announcing the project, students should demonstrate that they meet the necessary pre-condition to start the project. They need to have a Git repository for their project and also show the ability to successfully build the project.
  • Intermediate Report - Tool Usage: One third into the project, each group should hand in a status report containing screenshots of the tools applied on the project, and interpretations about these results.
  • Concluding Lecture: Two thirds into the project, there is a concluding session, where we will reflect on the lessons learned during the project.
  • Final Report: During the exam period you hand in a final report, listing the solutions for the problems you came across and what you learned from them. You will defend this report orally.

Below is the detailed time-schedule, which is subject to change. Changes will be notified over e-mail. [Last modified on February, 3rd, 2021.] 

week			 Wed 13:45 - 18:00 (Virtual)	
1		Wed 10-Feb	[T] Introduction (Serge)
2		Wed 17-Feb	[L] Metrics and Visualization (Henrique)
				[L] Duplicated Code (Henrique) 
3		Wed 24-Feb	-- no lecture (Talent Forum)
4		Wed 03-Mar	[L] Refactoring assistants (Henrique)
 				[L] Dynamic Analysis: Testing (Henrique)				
5		Wed 10-Mar	[L] Mining Repositories part 1 (John)
 				[L] Mining Repositories part 2 (John)
                                 >> hand out assignment here 	
6		Wed 17-Mar	[L] Free Project Work (remote work) 	
7		Wed 24-Mar	[L] Free Project Work (remote work) 
 				[Milestone 0] Groups Assembled + Precondition report
8		Wed 31-Mar	 -- no lecture (Go-Cart Race)	
  		Wed 07-Apr	 -- easter holiday	
 		Wed 14-Apr	 -- easter holiday	
9		Wed 21-Apr	[L] Free Project Work (remote work)
				[Milestone 1] Report on usage of tools
10		Wed 28-Apr	[L] Free Project Work (remote work)	
11		Wed 05-May	[L] Feedback session (remote work)
  				[Milestone 3] Feedback session
12		Wed 12-May	[L] Free Project Work (remote work)	
13		Wed 19-May	[L] Free Project Work (remote work)	

Course Material

All students should have read the following book; acquiring the terminology inside is required to write the final project report.


For the introductory lecture, there is a copy of the slides and a video recording of the lecture.

  • Slides "Reengineering Introduction" (Version February 2021) [Slides are available only in blackboard, for size and copyright reasons]
  • Video recording (Version February 2021) [You need a UAntwerpen login to watch the video]  


For the lab sessions there is the following material (please only get the materials after it is updated to the current year):

  1. Metrics and Visualization (Updated 2021-02-09)
  2. Duplicated Code (Updated 2021-02-12)
  3. Refactoring assistants (Updated 2021-02-23)
  4. Dynamic Analysis: Testing (Updated 2021-02-24)
  5. Mining Software Repositories (Updated 2021-03-08)

In the lab sessions, exemplary systems for experimenting with tools will be made available. However, you are encouraged to bring your own system along to the lab sessions; we will be happy to help you re-engineer your own project. Especially systems designed in Java (possibly with JUnit tests) are prime candidates to serve as subject systems. UPDATE 2021: Even with the course being fully virtual, we can still help you with your own systems. Just contact the TAs within a reasonable time frame for us to discuss on a case-by-case basis.

For old (outdated) sessions click here. The old material is for reference and backup only, you may see it and indulge your curiosity but please do not use outdated sessions. 



To demonstrate that you indeed acquired the range of principles, techniques, and skills that are currently being used for re-engineering students must restructure an existing software system to prepare for a given suite of new requirements. Note, that the extra functionality as such needs not be implemented; but that the existing design must be adjusted in such a way that adding the new functionality becomes a proverbial "piece of cake".

Project: Assignment 2021


  • Wednesday 24-Mar-2021 - 11h59 pm - Project Definition & Group Assembly & Precondition Report: Confirm your project (standard or custom) and group members by e-mail to Dr. Henrique Rocha and Dr. John Businge (please check the details on the subject and message content in the Assignment page). Include a precondition report, details of this report to follow on the Assignment page.
  • Wednesday 21-Apr-2021 - 11h59 pm - Intermediate Report - Tool Usage: Send the Intermediate Report (in PDF format) by e-mail to Dr. Henrique Rocha and Dr. John Businge.
  • 26-May-2021 11h59pm (**Date confirmed**; one week before the oral exam) - Final Report: Send the Report (in PDF format) by e-mail to Dr. Henrique Rocha and Dr. John Businge.
  • The oral exams themselves are scheduled on June 1rst or June 2nd (in the morning) virtually using Microsft Teams. See the detailed schedule below
To give you a taste of what projects have been used in the past, below is a list of the previous projects.

Note that you are allowed to propose a project yourself. To do that, send a simple e-mail to Henrique Rocha and John Businge motivating why the project you propose would allow you to demonstrate re-engineering skills.

Group work

It is possible (even encouraged) to work out the assignment in a group, but such a group will preferably not consist of more than three individuals. Of course, the expectations towards the end result of such a project are related to the size of the group. Also, remember that all members of the group will be given the same grade (report-wise).


The end result of this project consists of a written project report that needs to be elaborated upon during an oral project defense. Emphasis is on the solutions for the problems you came across and what you learned from them. Everything you claim in your project report must be backed up during the defense, using code and electronic documentation. The actual exam (= oral defense) takes place during the regular exam period and is scheduled accordingly. The report needs to be handed in a week beforehand electronically.

Guidelines for the Intermediate Report - Tool Usage

This report should be concise and to the point; its main purpose is to demonstrate that you have had personal hands-on experience with the tool suite explored in the lab sessions.

For each tool

  • show at least one screen-dump with the results of applying the tool on the project
  • provide brief interpretations (telegram style) of what you observe and what actions you would consider
  • give estimations on when your tasks will be completed

Guidelines for the Final Report

  • Short summary (Who, What, How): Who are the target users? What was the problem? How did we go about things?
  • Status: What did you do, and what is (possibly) going to happen next?
  • Which techniques and reengineering patterns did you use during requirements analysis, design, implementation, and testing. How did you identify the differences between the old requirements and the new ones, the old design and the new one? How did you transform the existing code into the new code? How did you ensure these restructurings did not introduce any errors?
  • Project process: Overview of planning, time schedule, and intermediary problems.

In the project report and during the project defense you should express yourself using the right terminology. (cfr . Object-Oriented Reengineering Patterns, Serge Demeyer, Stephane Ducasse, en Oscar Nierstrasz, Morgan Kaufmann, 2002).

Evaluation Criteria

  A. PRECONDITIONS: You have to meet the following entry criteria; if you don't your project report will be discarded without evaluation

  • You have submitted the Intermediate Report on Tool Usage on time
  • You did not copy other students work (we do check for plagiarism)

  B. SELECTION: In order to receive a passing grade (MINIMUM NORM), you have to show that you are at least capable of restructuring an existing software system.

  • You can extract the existing design from the available data (i.e. reverse engineering)
  • You can transform the existing source code so that it is more fit to implement the new requirements (i.e. refactoring)
  • You can demonstrate that the code transformations have not affected the existing functionality (i.e. regression tests)

  C. DIVERSIFICATION: To do better than a passing grade, you have to show that you have control over the restructuring process.

  • Which techniques (re-engineering patterns) did you use for the different phases? To what extent are you able to back up your choice?
  • How did you analyze the new requirements? To what extent will you be able to maintain control over future changing requirements?
  • How did you validate the design (architecture) that you extracted from the source code? How did you use this design to identify potential problems?
  • How did you handle the code transformation itself? Why will these transformations help to implement the new functionality which is to be added?
  • How did you check on the quality of your test procedure? To what extent are you able to justify the amount of time you put into the testing, related to the existing functionality and the improvements that were made?
  • How did you handle the restructuring process itself? How accurate were your planning and estimation? How did you react to unanticipated circumstances?

The following check-list will be used to assess your reengineering project

  • Checklist reengineering Pre-conditions Report (in English) [ PDF ]
  • Checklist reengineering Intermediate Report (in English) [ PDF ]
  • Checklist reengineering Final Report (in Dutch) [ PDF ]
  • Checklist reengineering Final Report (in English -- rough translation) [ PDF ]


Detailed exam schedule (Last modified on Friday May 28th, 2021)

Below is the detailed schedule for the oral exam (i.e. discussing the project report and your individual role in the project). If you see your name is missing, or if you spot any other mistakes, please contact Henrique Rocha ( immediately.

Tuesday, June 1rst 2021

  • 09:00  Robbe Van de Velde
  • 09:20  Freek De Sagher
  • 09:40  Lore Hilgert
  • 10:00  -- internal discussion

Wednesday, June 2nd 2021

  • 09:00  Ebert Schoofs
  • 09:20  Beau De Clercq
  • 09:40  -- internal discussion
  • 09:50  Max Van Houcke
  • 10:10  Thomas Van Onsem
  • 10:40  -- internal discussion
  • 10:50  Haroldas Latonas
  • 11:10  -- internal discussion
  • 11:20  Igor Schittekat
  • 11:40  -- internal discussion