Software Reengineering

Professor: 
Serge Demeyer
Assistant: Brent van Bladel

Practical

Who ?

  • Master Computer Science Period: 2nd semester 2016-2017

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: CMI.026 (PC Lab - Campus Middelheim), occasionlly in other rooms.

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

The realise these objectives, the course is organised 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. Afterwards 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).
  • Intermediate Report - Tool Usage: One third into the project, each group should hand in a status report containing screendumps 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, 14th 2017.]

week		Wed 13:45 - 18:00 G.026
1		Wed 15-Feb	**room G.015** [T] Introduction (Serge)
2		Wed 22-Feb	--
3		Wed 01-Mar	[L] Duplicated Code (Brent)
				[L] Metrics and Visualization (Brent) [G.026]
4		Wed 08-Mar	--
5		Wed 15-Mar	[L] Mining Repositories (Brent)
				[L] Refactoring assistants (Brent) [G.026]
6		Wed 22-Mar	--
7		Wed 29-Mar	>> [Milestone 0] Report groups
				-- go-cart race: no lecture
8		Wed 05-Apr	 -- easter holiday
  		Wed 12-Apr	 -- easter holiday
 		Wed 19-Apr	[L] Test Coverage and Dynamic Analysis (Brent)
				[L] Feature Location and Traceability (Brent) [G.026]
9		Wed 26-Apr	>> [Milestone 1] Report on usage of tools
10		Wed 03-May	[L] Free Project Work [G.026]
11		Wed 10-May	--
12		Wed 17-May	[T] Conclusion (Serge)
13		Wed 24-May	--
 		Wed 31-May	Start of exam period

Course Material

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

Additionally, there is also the following course material

For the lab sessions there is the following material:

  • 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-engineering your own project. Especially systems designed in Java (possibly with JUnit tests) are prime candidates to serve as subject systems.
  • ...

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 2017

Milestones

  • Wednesday 29-Mar-2017 - 11h59 pm - Announce Project: Confirm project and project groups by e-mail to Brent van Bladel and Serge Demeyer
  • Wednesday 26-Apr-2017 - 11h59 pm - Intermediate Report - Tool Usage: Send a link to the Intermediate Report in PDF by e-mail to Brent van Bladel and Serge Demeyer
  • ??? - Final Report: Send a link to the Report in PDF by e-mail to Brent van Bladel and Serge Demeyer
    • The exams themselves are scheduled on June XXX. 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 Serge Demeyer and Brent van Bladel 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 final 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 Intermediate Report - Tool Usage

This report should be concise and to the point; it's main purpose is demonstrating that you have had peronal 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

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

  1. PRECONDITIONS: You have to meet the following entry criteria; if you don't your project report will be disarded 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)
  2. 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)
  3. 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 analyse 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 was your planning and estimation? How did you react to unanticipated circumstances ?

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

  • Check list reengineering project (in Dutch) [ PDF ]
  • Check list reengineering project (in English -- Early Draft; rough translation) [ RTF ]

 

Detailed exam schedule

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 you name is missing or spot any other mistakes, please contact Prof. Serge Demeyer immediately.

xxx, July xx 2017 - room CMI.G106b			
	10:30	11:00	...
 	11:00	11:30	...
 	11:30	12:00	..