4th Workshop on Object-Oriented Architectural Evolution

ORGANIZERS

Tom Mens (tommens@vub.ac.be)
Programming Technology Lab, Vrije Universiteit Brussel, Brussels, Belgium

Galal Hassan Galal (galal@acm.org)

School of Computing Science, Middlesex University, London, United Kingdom

INTRODUCTION

This workshop is the fourth in a series of workshops in the area of software architecture and its evolution, which took place during ECOOP 1998, ECOOP 1999 and ECOOP 2000. Previous workshops have proved very successful and stimulating, culminating in reports that contained novel and exciting views on what software architecture is, or should be, and how architectural issues may be approached from fresh perspectives. Past workshops also incorporated relevant experience reports and suggestions for future research in the area of evolving software architectures, especially object-oriented ones.

All information about the ECOOP workshop series on object-oriented architectural evolution can be found at prog.vub.ac.be/OOAE/.

WORKSHOP FORMAT

The nature of the ECOOP 2001 workshop on object-oriented architectural evolution is intended to be incremental, building further on the results of the last three years. To ensure an active collaboration between the participants, the call for participation is built up in a Q&A-style. After a briefing of the results of the previous workshops, a number of tentative open questions is suggested to which participants should try and provide an answer before the workshop. During the workshop, the different positions of the participants will be discussed.

BRIEFING OF PREVIOUS WORKSHOPS

The ECOOP 2000 workshop on object-oriented architectural evolution aimed at distilling those issues that should become part of any future research agenda into the evolution of object-oriented software architectures. This resulted in three main results which deviate significantly from the mainstraim view of what software architectural evolution is or how it might be researched:

  1. A "revolutionary" definition of software architecture

    Current definitions of software architectures are too static, in the sense that they do not include the time dimension (as opposed to the ideas in architecture of buildings, such as [Brand1994]). They do not take evolution aspects into account, and only focus on how software components interconnect (e.g. using the notion of architectural connectors and components).

    Since it is very important that a software architecture should be robust towards evolution, the quality requirement of stability (or robustness) was considered essential, resulting in the following definition of a software architecture:

    "A software architecture is a collection of categories of elements that share the same likelihood of change. Each category contains software elements that exhibit shared stability characteristics."

    This definition deviates quite a lot from more standard notions of software architecture. The main motivation is that changes in software requirements should have a minimal impact on the software architecture. Architectural stability refers to the ease with which an existing software architecture accomodates changes of functionality, platform, etc.

  2. The relationship between domain analysis and architectural modelling

    The problem domain has a major role to play in deriving software architectures, as well as reasoning about them. By performing a careful domain analysis, it should be possible to derive a better (i.e. more stable) software architecture. Also, based on domain analysis it should be possible to better predict certain types of architectural evolution. Again, this is a major theme that emerged from last workshop, and appears to be seriously under-represented in the literature.

  3. The relationship between software architecture and software implementation

    Given the above "revolutionary" definition of software architecture, an architecture should capture much more than only the software structure. This is again different from mainstream definitions of software architectures that tend to assume a one-to-one relationship between a software architecture and the software implementation. Instead, the working group agreed that a single architectural view is not sufficient, and proposed to use multiple architectural views (of which a structural view on the software can be one). Some of these views may be domain-specific, while others may be more "technical". Architectural views can be seen as the "categories" in our definition of software architecture.

    The working group also proposed to take a layered approach to software architectures. This allows for a more gradual transition from software architecture to implementation. Such a layered representation is useful in managing architectural evolution at the appropriate level of detail.

OPEN QUESTIONS

Starting from these three main results, a number of important questions arise that deserve further attention. Below we give a tentative list of these questions, subdivided into 5 categories:
  1. Questions related to domain analysis:
  2. Questions concerning the use of multiple architectural views:
  3. Questions concerning the layered approach:
  4. Impact of multi-layered view approach on architectural evolution:
  5. Applicability of existing techniques:

WORKSHOP PARTICIPATION

  1. Submission

    As opposed to previous years, we do NOT expect a position paper from the participants. Instead, attendees to the ECOOP 2001 workshop on object-oriented architectural evolution should either: Whereever possible, given argumentations must be accompanied by concrete examples.

    Additionally, participants should try to pose some new related questions (preferably with some motivation and even a partial answer) that seem important to address as well. The most relevant questions will be incorporated in the tentative list so that other participants have a possibility to have a look at them and formulate an opinion about them before the workshop.

    Participants who wish to provide a relevant (short) position paper as an adjunct to their responses (but not instead of), for the participants to read, may do so. Such papers will be made available on the website, but will not be published as part of the workshop proceedings. Moreover, any required copyright clearance must be obtained by the individual concerned before submission.

    Submission format. To facilitate processing, submissions should be written in plain ASCII text (no pictures or special formatting) and should be between 300 and 1000 words in length. Of course, one can always refer to accessible papers to strengthen a particular viewpoint.

    Submission procedure. Submissions should be sent by e-mail to Tom Mens (tommens@vub.ac.be) with a CC to Galal Galal (galal@acm.org). The ASCII text of the submission should be directly inlined in the e-mail body. Moreover, the e-mail body should include the authors’ name, address, e-mail address, and affiliation.

  2. During the workshop

    Based on the answers gathered before the workshop, participants will be divided into groups to further discuss deviating views, or to further work out some partially answered questions.
    Participants may bring with them to the workshops illustrative diagrams on transparencies, to help in summarising their positions.

  3. Results

    As per the tradition with past ECOOP workshops, a synopsis of the workshop's discussions, as well as any convergences of view taking place during the workshop, will be collated into a technical report which will be made available on the organisers' website. It is also expected, again as per ECOOP tradition, that such a synopsis will be published by Springer Verlag in an LNCS volume containing the ECOOP Workshop Reader.

IMPORTANT DATES

ABOUT THE ORGANISERS

Tom Mens is a postdoctoral fellow of the Fund for Scientific Research - Flanders (Belgium) since October 2000. He is associated as a computer science researcher to the Programming Technology Lab of the Vrije Universiteit Brussel, where he finished his PhD on "A Formal Foundation for Object-Oriented Evolution" in September 1999. In 1998 he was part of the ECOOP Organizing Team. He actively contributed to the last three ECOOP workshops on Object-Oriented Architectural Evolution. His main research interest lies in the use of formal techniques for improving support for software evolution, and he published several papers on this research topic. In the EMOOSE-programme (European Masters in Object-Oriented Software Engineering), jointly organised by the Vrije Universiteit Brussel (Belgium) and the Ecole des Mines de Nantes (France), he gives an advanced course on object-oriented software evolution. Finally, he is co-founder and coordinator of the Scientific Research Network on Foundations of Software Evolution, financed by the Fund for Scientific Research - Flanders (Belgium).

Galal Hassan Galal is currently a principal lecturer in Computing Science at Middlesex University. He lectured on a large variety of Software Engineering and Information Systems topics at Brunel University to undergraduate and postgraduate students. He also published in the areas of Software Engineering, Information Systems and Knowledge-Based Systems. His research interests include software and systems engineering methodologies, requirements engineering and systems architecting. He completed his Ph.D. in 1996 at Brunel University on Information Systems Engineering. Galal has taken up studying Architecture (as in buildings) formally and is currently in his third year of a part-time degree in Architecture. Galal has co-organised the ECOOP 1999 and ECOOP 2000 workshops on Object-Oriented Architectural Evolution.

RELATED WORKSHOPS

RELEVANT LITERATURE

An extensive list of relevant literature and web sites can be found in the ECOOP 2000 Workshop Synthesis, which is accessible via prog.vub.ac.be/OOAE/ECOOP2000/ECOOP2000-OOAE.html.
The following references are also relevant.

This workshop is an offical activity of the Scientific Research Network on "Foundations of Software Evolution", and is partially financed by the Fund for Scientific Research - Flanders (Belgium).