Themes of cooperation between Humboldt University Berlin and
Universities in South Eastern Europe

Preliminary remarks:

a) This document should be considered as a proposal and an offer by Humboldt University Berlin (HU) to cooperate in the field of software engineering education, or more generally in the field of software engineering.

b) The idea is to center activities around an existing software system - the system XCTL - that is subject of project work in an educational environment at computer science curriculum at HU.

c) The list below is not disjunctive - there may be intersections between two or more proposed themes.

d) Proposed themes may be used as research activities which can be implemented by means of student's projects as well.

e) In particular, themes can also be used for master theses (diploma theses) for students

f) Topics can be assigned to one location as well as treated in a joint project of several partners (which could be more inspiring)

g) Treatment of subjects below is no automatism, the themes are (at least partly) only a frame to be filled by you.

h) Since this list of subjects should be treated as a proposal, each of you is invited to add other subjects of interest.

List of subjects as a basis of cooperation: overview

1. Reengineering (restoring, improving, restructuring) subsystems of the XCTL system
   possible: reimplementation of whole subsystems
2. Distributed software engineering over the internet: common treatment of a legacy system
3. Concurrent software reengineering: experimenting with different reengineering strategies
4. Tool development: statical and dynamical analysis of C++ programs - for dead code detection, trace analysis, test case coverage C0, C1, ...) ...
5. Software design recovery and rearchitecturing
6. Formal specification of subsystems: Z, SDL
7. Portability issues
8. Use of XCTL in software engineering education: students' projects e. g. distributed software projects, experience reports

List of subjects as a basis of cooperation: details

1. Restoring (reengineering, improve) subsystems of the XCTL system
   • XCTL as a legacy system includes a lot of poor coding structures which should be improved. There is a strategy called refactoring with which bad code is being improved step by step. In a recent book by M. Fowler, refactoring is applied to Java. This can be the basis of the work. However, it can also be the source of ideas for new refactoring steps.
   • There are several subsystems of XCTL corresponding to use cases that can be handled independently. Thus, these independent pieces of code could be handled by different groups. In addition, it also can be an idea that the same code is being considered and modified by different groups, thus, comparing the results at the end.
   • Remark: A clean subsystem structure with (relatively) well-defined interfaces is just being implemented but not completed yet.
   • This procedure should be accompanied by several other measures:
     • In a first step, a review of the code should take place.
     • There has to be a solid set of test cases to make sure the correctness after each improvement step.
     • The test as a regression test should be automatized.
     • The procedure should be software metrics based to compare the quality of different program versions
   • Remark: There is a certain set of test cases by now, but these tests are not yet complete. There is also a first version of an automatic testing application (developed by one of our students).
2. Distributed software engineering over the internet: common treatment of a legacy system
   • The tasks described in the paragraph above could also be performed by a distributed team that communicates its work and progress through emails. This may lead to additional communication overhead but could as well be quite inspiring and - since the task management needs to be more strict and precise - it could result in higher quality of the solutions.
3. Concurrent software reengineering: experimenting with different reengineering strategies
   • Another alternative to the two suggestions above could be a kind of small competition where all participants are expected to examine and improve the same subsystem. Each step and all applied techniques and, of course, the tools used should be documented. Subsequently there could be a comparison of the resulting subsystems. This could be a means to assess the cost benefit ratio of the different actions that took place during the improvement processes.
4. Tool development: statical and dynamical analysis of C++ programs
   • The XCTL system sources are highly loaded with unfinished and unneeded code fragments. A well performing dead code analysis (plus removing the dead code parts) would certainly raise the comprehensibility of the XCTL system. This dead code analysis not only needs to check for unreachable functions but also needs to detect single lines (e.g. case statements) that cannot be reached.
   • A trace analysis is useful for several purposes. It could, for example, check whether the system is well partitioned in subsystems or not. For testing purposes a trace of programm runs would also be quite useful. A trace analysis tool should not only allow to profile a program run. It should also be able to instrument the code to produce traces.
   • All these tools (and several more) would greatly benefit from a more or less universal C++ parser with a well defined interface to access cross reference information. It should be analysed if there are freely available and useful C++ parsers or if a C++ parser could be extracted from the gcc (GNU Compiler Collection - www.gcc.org) sources.
5. Software design recovery and rearchitecturing: applying URCA
   • There is a use case diagram regarding the XCTL system. By now a non-formal description of the use cases has been developed. These short content descriptions will soon be available in English. Based on these use cases the URCA tool should be applied to recover the software design. The results could be used to determine whether the actual partitioning of the source code into subsystems is reasonable or not. If not, suggestions for a better partitioning should be made.
6. Formal specification of subsystems: Z, SDL
   • The XCTL system is partitioned into several subsystems. Since the XCTL system is legacy software and the subsystems have been extracted through a reverse engineering process there are no formal specifications concerning the behaviour of these subsystems available. Formal specicifications could be a means for a better comprehension and an easier way to specify test cases for certain subsystems. Besides a specification with Z a specification using SDL (Specification Development Language - www.sdl-forum.org/SDL/index.htm) could be quite useful.
7. Portability issues
   • The XCTL system is a 16 Bit application for Microsoft Windows developed with Borland C++. It is used with Windows 3.1. It is planned to migrate to Windows 9x (plus porting the system to 32 Bit) but there are several pitfalls with this decision.
   • A lot of additional problems arise from the wish to use Microsoft Visual C++ instead of Borland C++. Therefore the XCTL system needs to be closely examined for problems that could show up during a porting. Based on the results of this examination a detailed porting plan should be developed.
8. Use of XCTL in software engineering education: students' projects
   • SE education at universities needs project work. To this end, teams of students should cooperate in developing or maintaining (reengineering) a software project.
   • At HU, the XCTL system has been sucessfully used for educational purposes in all phases of SW development and as a demonstration for each kind of software documents: requirements specification, use case model, SW architecture, code, test cases, and others. It has been used, as well, for practicing process activities, e. g. reviewing documents (in teams), organizing group meetings, version management of code sources, establishing a repository of all projects documents, deriving a test set and others.
   • XCTL project documents are not complete yet, and a goal could be to extend and improve the system to approach an 'ideal solution' for demonstrational purposes. Experiences made by different universities could be compared and generalized.

© 2001, Kay Schützler (E-Mail, Homepage)