Report on ESEC/FSE 2003

advertisement
Report on ESEC/FSE 2003
By Jingyue Li and Finn Olav Bjørnson
Place: Helsinki, Finland
Time: September 1-5, 2003
ESEC/FSE 2003 was the joint meeting of the 9th European Software Engineering Conference
(ESEC) and of the 11th ACM SIGSOFT Symposium on the Foundation of Software Engineering
(FSE). The joint events takes place every two years in Europe, bringing together researchers and
practitioners of software engineering to report on innovative research results and to exchange
experience related to both traditional and emerging areas in software development.
The conference includes two parts, tutorials and workshops in the first and second day and
conference sessions in the later three days. Because the feature oriented programming and
product-line tutorial was cancelled, we took part in three tutorials (software architecture
reconstruction, software evolution, and OO testing). We also listened to all the presentations in the
conference. The following is the summary of the most interesting research topics from our point of
view (Component based software engineering)
Software architecture reconstruction (tutorial)
The software architecture reconstruction tutorial was hold by Claudio Riva (Nokia Research
Center). He introduced reconstruction process, tools, and Nokia case study. Their process includes
three parts i.e. extraction, abstraction and presentation. The goal of extraction phase is to extract a
source code model for the system that contains only the most relevant information. There are two
strategies for analyzing the source code and for extracting the relevant information:
1. Extracting the typical programming languages construct from code using front-ends tools
such as grep, perl, source navigator., sniff++, and Columbus.
2. Extracting domain specific information from code and artefacts.
The goal of abstraction phase is to reduce the complexity in the source code model, generate
different views of the model and re-document the system. Nokia used Rigi tool to support
visualization and abstraction. Basically, this phase is done by researchers and domain experts
manually. It is also the most time-consuming phase.
The goal of presentation phase is to create a graphical or textual representation of the architectural
model. Tools like UML with Visio and Rational Rose are used in this phase.
Another important issue in software architecture reconstruction is dynamic analysis. Nokia
approach is:
1. Select a feature to analyze and define a use case
2. Execute the use case on the instrumented software and collect the traces
3. Create the feature view by combining the traces with the high-level static view
4. Abstract the feature view by detecting interaction patterns
5. Navigate the feature view by expanding/collapsing the participants and messages, by filtering
un-relevant information and by slicing the static views with particular dynamic scenarios.
Possible research direction: The result of Nokia software structure reconstruction is their product
family. Jinguye has identified two Norwegian IT companies, such as DNV and Visma, involved in
family project that also have this kind of requirement. Possible research direction is to do case
study and provide proposal on how to reverse engineering their old system to product family.
Software evolution (tutorial)
The software architecture reconstruction tutorial was held by Meir M. Lehman from Middlesex
university. The theory and rules of software evolution were introduced. The recent empirical study
(effort estimation in the continual evolution) done by his student J. F. Ramil was also introduced.
The basic idea was to use a evolution simulation model to simulate the effort of continual
evolution first, and then use empirical data to test it. Furthermore, strategies on evolution
management and release management were also introduced.
Possible research direction: The challenges related to component based developmenet are as
follows:
1. Determine if, why and how components are sensitive to evolution
2. Derive implications of laws of software evolution in component context
3. Investigate means to mitigate and control impact.
4. One hypothesis: Invalid assumptions constitute major trigger of misbehavior in execution,
defects, project delays, cost over-runs, failure. So how to control the assumptions inside and
outside components is a very important issue.
Object Oriented Testing (tutorial)
The tutorial was held by Mauro Pezzè and Michael Young. It detailed tests in the context of OO
software, state dependent behavior and how to construct test cases in order to insure coverage of
all transitions in finite state machines and how to apply this to concepts like inheritance,
polymorphism and dynamic binding. We found the tutorial to be interesting, but not relevant to
our main focus which was component based development. We only attended the tutorial because
the tutorial on feature oriented programming and product-lines was cancelled.
The Conference
The main conference started on Wednesday. Each day was divided into four parts. The day started
with an invited speaker, which was followed by three sessions, each with a new topic. Wednesday
started with G. Longo giving a speak on Computer Modelling and Natural Phenomena, then we
were presented with three sessions, the first on Requirements Engineering and Design the second
on Software Architectures, Patterns and Frameworks and the third on testing and Test Tools.
Thursday started with L. J. Osterweil giving a speak on Understanding Process and the Quest for
Deeper Questions in Software Engineering Research. The speak was followed by a session on
Software process and workflow, a session on Validation and Verification and a session on
Software Reuse and Evolution. The last day of the conference, Friday, started with A. Jaaksi
giving a speak on Assessing Software Projects – Tools for Business Owners. This was followed by
a session on Software Analysis and Model Checking, a session on Component-Based Software
Engineering and the final session which was on Safety and Security.
From our point of view the session on component based software engineering was the most
relevant session to our work. The session and possible research directions is outlined below:
Component based software engineering (conference session)
In this conference, three papers were presented in the CBSE session. All of them by americans.
One of the more interesting papers was published by a Ph.D Student from MIT. The title was
“Predicting problems caused by component updates”. The goal of this research is to enhance the
reliability of software upgrades by predicting upgrades that may cause system failure or
misbehavior, as might occur when a supposedly compatible upgrade is used in a situation for
which it was not designed or tested. The key question is “Will upgrading a component, which has
been tested by its author, causes a system that uses the component failure”. In order to reduce
costs by detection early in the upgrade process, they try to answer this question before integrating
the new component into the system or fielding and testing the new system. Their technique
generates an operational abstraction for the old component in the context of the system and
generates an operation abstraction for the new component in the context of its test suite; an
operation abstraction is a set of program properties that generalizes over observed run-time
behavior. If automated logical comparison indicates that the new component does not make all the
guarantees that the old one did, then the upgrade may affect system behavior and should not be
performed without future scrutiny.
Possible research direction: One of the key issues in component evolution is to make sure that it
can still work correctly after upgrade. Generally, regression test will be performed. However, in
some cases, such as product line, changing a component in the core asset will affect a lot of
products. As a result, it is necessary to do some prediction before integrating the components into
product line even regression is recommended afterwards. In other case, if your want to upgrade
the COTS or OSS components or select a replaceable new components from other COTS vendors,
it is very valuable to do problem prediction before integrate it into application.
Download