Home › Courses › Software Reengineering

Software Reengineering

Professor: 
Serge Demeyer
Assistants: Mutlu Beyazıt, Onur Kilincceker

Practical

Who ?

  • Master Computer Science Period: 2nd semester 2023-2024

Where ? When ?

  • Theory & Exercises all during the same time slot
  • Time: Wednesday 13:45 - 18:00 (session usually end sooner)
  • Location: Campus Middelheim - PC Class G.026

Course Content

This course concerns the 'state-of-the-art' concerning 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).

This course is offered every 2 years. It will NOT be offered in 2023-2024; 2025-2026... but will be offered in 2024-2025; 2026-2027; .... 

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.

Milestones

  • 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.
  • Feedback Session: Two thirds into the project, there is a feedback session, where we will reflect on some issues discovered 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, 5th, 2024.] 

week		 Wed 13:45 - 18:00 G.026	
1	Wed 14-Feb	[T] Introduction	
2	Wed 21-Feb	[L] Metrics and Visualization [L] Duplicate Code
3	Wed 28-Feb	[L] Refactoring Assistants [L] Dynamic Analysis: Testing	
4	Wed 06-Mar	[L] Feature Location an Traceability [L] Mining Software Repositories
 	 >> hand out assignment in week 4
5	Wed 13-Mar	[L] Free Project Work	
6	Wed 20-Mar	[L] Free Project Work	[Milestone 0] Groups Assembled + Precondition Report
7	Wed 27-Mar	[L] Free Project Work	
	Wed 03-Apr	 -- easter holiday	
 	Wed 10-Apr	 -- easter holiday	
8	Wed 17-Apr	[L] Free Project Work	[Milestone 1] Report on usage of tools
9	Wed 24-Apr	[L] Free Project Work	
10	Wed 01-May	 -- holiday
11	Wed 08-May	[L] Feedback session	[Milestone 2] Feedback session	
12	Wed 15-May	[L] Free Project Work	
13	Wed 22-May	[L] Free Project Work	
 	Wed 29-May	 -- exam period

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 paper to read, a copy of the slides and a video recording of the lecture.

 

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
  2. Duplicated Code
  3. Refactoring Assistants
  4. Dynamic Analysis: Testing
  5. Feature Location
  6. Mining Software Repositories

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 or Python (possibly with associated unit tests) are prime candidates to serve as subject systems.

For old (outdated) sessions click here and 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. 

 

Project

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 2024 - Pick one of the following.
    • Project Assignment 2024 - MUTMUT
    • Your Own Custom Project - You are encouraged to define your own project.
      • The scope of the project should be similar to the ones offered in the course in this semester or previously.
      • You should act in a timely manner to discuss your project with us.
      • You can target one of the software systems used in the assigned projects and define a different set of tasks, or you can use a completely different software system.

Milestones

  • Wednesday 20-Mar-2024 - 20:00 - Project Definition & Group Assembly & Precondition Report: Confirm your project (standard or custom) and group members by e-mail to Mutlu Beyazıt (Mutlu.Beyazit@uantwerpen.be) and Onur Kilincceker (Onur.Kilincceker@uantwerpen.be). Include a precondition report, as instructed on the Assignment page.
  • Wednesday 17-Apr-2024 - 20:00 - Intermediate Report - Tool Usage: Send the Intermediate Report (in PDF format) by e-mail to Mutlu Beyazıt (Mutlu.Beyazit@uantwerpen.be) and Onur Kilincceker (Onur.Kilincceker@uantwerpen.be).
  • Monday, 27-May-2024 - 12:00 (3 days before the oral exam) - Final Report: Send the Report (in PDF format) by e-mail to Mutlu Beyazıt (Mutlu.Beyazit@uantwerpen.be) and Onur Kilincceker (Onur.Kilincceker@uantwerpen.be).
  • The oral exams themselves are scheduled on Friday, May 31st. 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 Onur Kilincceker and Mutlu Beyazıt 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 should 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.

Exam

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 Precondition Report - Project & Group

Your Pre-conditions Report should contain the following:

  • Project Name (to be sure you are working on the suggested project or a custom one)
  • Full Name of all the members in your group
  • Link to your git repository
  • The members are set as collaborators to the git project.
  • The assistants were invited as collaborators (ask Mutlu and Onur for their respective identifiers).
  • Demonstrate the ability to build the project. For this, we want a statement from the group attesting they managed to successfully build the project. You can also attach a screenshot of your IDE with the project source and a message like "build successful".

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 ]

 

Copied Code - Code created by Generative AI

For project work, students may copy code from the internet, but must do so explicit attribution of the source where it is copied from. Students may use generative AI tools for the code of their project, but must do so with explicit acknowledgment, i.e. it must be clearly indicated which code was created by which tools. In an oral exam of the assignment or during a contact moment, students are expected to elaborate on their assignment (and how they used generative AI).

Reports written with support from generative AI

Students may use generative AI tools as a tool during their assignment, similar to initial search engines such as Google and for checking grammar and spelling. In an oral exam of the assignment or during a contact moment, students are expected to elaborate on their assignment (and how they used generative AI).

 

Detailed exam schedule (Last modified on Friday, May 3rd)

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 Prof. Serge Demeyer immediately.

FRIDAY, May 31st, 2024

  • Exams in room CMI. G 106b (office prof. Serge Demeyer)
  • 09:30  -- internal discussion
  • 09:40 ... (G1)
  • 09:55 ... (G1)
  • 10:10 ... (G1)
  • 10:25  -- internal discussion
  • 10:30 ... (G2)
  • 10:45 ... (G2)
  • 11:00 ... (G2)
  • 11:15 -- internal dicussion
  • 11:20 ... (G3)
  • 11:35 ... (G3)
  • 11:50  -- internal discussion
  • 11:55 ... (G4)
  • 12:10  -- internal discussion
Last modified:
Monday, March 8, 2021 - 18:13