LORE logo  University of Antwerp
 Department of Mathematics and Computer Sciences
 Lab On REengineering
 This page: http://lore.ua.ac.be/Teaching/SReengMaster/oldindex.php?print=true
 [Normal Page]

Time Schedule | Course Material | Project | Exam |

LORE / Teaching / SReengMaster

The exam is scheduled for Wednesday, june 29th in Prof. Demeyer's office (Room CMI.G.106b). Project reports are expected one week earlier, wednesday june 22nd. Submit your project reports electronically via blackboard !!

The fine-grained schedule for the project defenses (20 minutes per student).

9:30 - Wuytjens Gino
9:50 - De Smedt Philip
10:10 - Slowack	 Jelle
10:30 - Nagy Akos Gergo

-- 10 minute break

11:00 - Cabello Martin Raul
11:20 - Buyl Kevin
11:40 - De Vylder Thomas
12:00 - Riegelhaupt Daniel

If names are missing from the above list, or if you spot any other mistakes, please contact prof. Serge Demeyer immediately.

Students: Master Computer Science
Period: 2nd semester 2010-2011

Professor: Prof. S. Demeyer

Assistants: Sylvain Degrandsart (For the project), Jan Vlegels, Ahmed Lamkanfi, Quinten David Soetens.

Theory & Exercises
Time: Wed 13:45 - 17:00
Location: CGR.V.029 (Campus Groenenborger) / CMI.G.026 (Campus Middelheim)

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 several 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 in 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. Halfway through the project, we organise a concluding session, where we will reflect on the lessons learned during the project.

Below is the detailed time-schedule, which is subject to change. Changes will be notified over e-mail. [Last modified on: February, 11th 2011.]

2nd semester		SReMAS (T en P)
week		 Wed 13:45 - 17:00 CGR.V.029 / CMI.G.026
1	16-Feb	
2	23-Feb	[T] Introduction (Serge) -- CGR.V.029
3	2-Mar	[L] Duplicated Code (Jan Vlegels) -- CMI.G.026
4	9-Mar	[L] Metrics and Visualization (Quinten) -- CMI.G.026
5	16-Mar	[L] Mining Repositories (Ahmed) -- CMI.G.026
6	23-Mar	[L] Testing en Dynamische Analyse (Ahmed) -- CMI.G.026
7	30-Mar	Labo rescheduled to April 27th
8	27-Apr	[L] Agile approaches (Jan) -- CMI.G.026
 	13-Apr	 -- easter holidays
 	20-Apr	 -- easter holidays
9	27-Apr	
10	4-May	
11	11-May	[T] Conclusion (Serge) -- CGR.V.029
12	18-May	
13	25-May	

Course Material

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

Book Cover Book Cover

Additionally, there is also the following course material

  • Slides "Introduction" (08-02-2010) [ PDF | PPT ].
  • Work collection Duplication Lab Session [ TJZ,32MB ].
  • Book Working Effectively with Legacy Code by Michael Feathers. The library has 4 copies.
  • In the lab sessions, exemplary systems for testing techniques will be made available. Should you bring your own system to class, we will be happy to help you out 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".

>>>>>The project is described in Assignment 2011.<<<<<

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 Sylvain Degrandsart 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 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. 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)
  2. 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 ?

 

 

 Lab On REengineering - Antwerpen, last modified 11:13:38 07 June 2011