4th Workshop on Object-Oriented Architectural Evolution
Programming Technology Lab, Vrije Universiteit Brussel, Brussels, Belgium
Galal Hassan Galal
School of Computing Science, Middlesex University, London, United Kingdom
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/.
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
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:
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.
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.
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.
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:
- Questions related to domain analysis:
- What is the precise relationship between domain modelling and architectural design/modelling?
- How can domain analysis be used to derive a better (i.e. more stable) software architecture?
- Can we predict certain types of architectural evolution based on a given domain analysis? Which ones? How?
- Questions concerning the use of multiple architectural views:
- Should there be a predefined set of architectural views, or do the kinds of views depend on the problem domain?
- Is there a relationship between the different architectural views? Should we allow for explicit constraints between the views? How? Why (not)?
- Is there a correspondence between the architectural views and the architectural styles that can be used in those views?
- Questions concerning the layered approach:
- How should the different layers be related? Should we put explicit constraints between them? How?
- Should there be a limited set of layers depending on the architectural view taken, or can there be an unlimited number of layers?
- How can layering ease the transition from a software architecture to the
(object-oriented) software implementation?
- (How) can other architectural styles than a layered one be used to (i) facilitate evolution; (ii) ease the transition to the software implementation?
- Impact of multi-layered view approach on architectural evolution:
- How can views be used to guide/constrain/facilitate changes to the architecture and the implementation?
- Does it make sense to distinguish inter-view, intra-view, inter-layer and intra-layer evolution? What is the meaning of this?
- Can a multi-layered-view approach be beneficial for checking or enforcing the conformance of a software implementation to its architecture? Does it become simpler to synchronise an architecture and its corresponding implementation?
- Applicability of existing techniques:
- Where do existing evolution approaches like reverse engineering, architectural recovery, restructuring, refactoring, architectural reconfiguration fit in? Can they be used in the above approach? How can they benefit from the ideas introduced above?
- Can object-oriented techniques such as design patterns, frameworks and inheritance be used to facilitate evolution, or to ease the transition from a software architecture to a software implementation?
- How can one determine whether (part of) a given software architecture is stable?
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.
- Provide (partial) answers to at least three of the above sub-questions
- Provide (partial) answers to at least one of the above main questions with its constituent sub-parts
- Counter or overthrow one of last year's results, by giving a precise motivation of why you don't agree, and propose an alternative definition or approach
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 (email@example.com)
with a CC to Galal Galal (firstname.lastname@example.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.
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.
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.
- April 1, 2001: Submission of workshop participation.
- May 1, 2001: Notification of acceptance.
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.
- FFSE 2001 (March 13, 2001. Lisboa, Portugal)
International Special Session on Formal Foundations of Software Evolution
- ISPSE 2000 (Nov. 1 & 2, 2000. Kanazawa, Japan)
International Symposium on Principles of Software Evolution
- ECOOP 2000 Workshop 17 (June 13, 2000. Sophia-Antipolis, France)
Object-Oriented Architectural Evolution
- ECOOP 1999 Workshop 04 (June 15, 1999. Lisboa, Portugal)
Object-Oriented Architectural Evolution
- ECOOP 1998 Workshop 02 (July 20, 1998. Brussel, Belgium)
Techniques, Tools and Formalisms for capturing and assessing Architectural Quality in Object-Oriented Software
An extensive list of relevant literature and web sites can be found in the ECOOP 2000 Workshop Synthesis, which is accessible
The following references are also relevant.
- S. Brand.
How Buildings Learn.
Phoenix Ltd., ISBN 0-75380-0500, 1994.
- P. Kruchten.
The 4+1 View Model of Architecture.
IEEE Software 12(6): 42-50, 1995.
- K. Mens, R. Wuyts.
Declaratively Codifying Software Architectures Using Virtual Software Classifications.
Proc. TOOLS Europe '99, pp. 33-45, IEEE Computer Society Press, 1999.
- K. Mens.
Automating Architectural Conformance Checking by means of Logic Meta Programming.
PhD Thesis, Vrije Universiteit Brussel, October 2000.
- G.C. Murphy, D.Notkin, K. Sullivan
Software Reflexion Models: Bridging the Gap Between Source and High-Level Models.
Proc. Third ACM SIGSOFT Symp. Foundations of Software Engineering, pp. 18-28, ACM Press, July 1996.
- T. Richner, S. Ducasse.
Recovering High-Level Views of Object-Oriented Applications from Static and Dynamic Information.
Proc. Int. Conf. Softw. Maintenance, pp. 13-22, Hongji Yang and Lee White (Eds.), IEEE Computer Society Press, September 1999.
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).