Design erosion is a common problem in software engineering. We have found that invariably, no matter how ambitious the intentions of the designers were, software designs tend to erode over time to the point that redesigning from scratch becomes a viable alternative compared to prolonging the life of the existing design. In this paper we illustrate how design erosion works by presenting the evolution of the design of a small software system. In our analysis of this example we show how design decisions accumalate and become invalid because of new requirements. Also it is argued that even an optimal strategy for designing the system (i.e. no compromises with respect to e.g. cost are made) does not lead to an optimal design because of unforseen requirement changes that invalidate design decisions that once were optimal.

Evolution of software architectures is, different from architectural design, an area that only few tools have covered. We claim this is due to the lack of support for an important concept of architectural evolution: the notion of architectural design decisions. The absence of

Without rigorous software development and maintenance, software tends to lose its original architectural structure and become more difficult to understand and modify. ArchJava, a recently proposed implementation language which embeds a component-and-connector architectural specification within Java implementation code, offers the promise of preventing the loss of architectural structure. We describe a case study in which we incrementally re-engineer an existing implementation with an eroded architecture to obtain an ArchJava implementation that more closely matches an idealized architecture. Building on results from similar case studies, we chose an application consisting of over 16,000 source lines of Java code and 80 classes that exhibited many characteristics of real-world legacy applications. We describe our process, some lessons learned, as well as some perceived limitations with the tools, techniques and languages we used. 1.

In this paper, we connect the notion of software maintainability with the problem of software deterioration. We propose a model that incorporates both of these aspects, which gives us a vocabulary and a more formal tool than before, and allows us to discuss how to maintain software so as not to make it deteriorate.

The documentation of software artifacts in general, and object-oriented frameworks in particular, has always been problematic. In this paper, we advocate the use of a declarative meta-programming environment to document software artifacts. In particular, we show how a significant and important part of the design of a framework can be adequately and concisely documented in such an environment, and how this allows us to use this documentation in an active way.

The ever growing size and complexity of software systems is making it increasingly harder to built systems that both meet current and future requirements. During architecture design, a lot of important design decisions are taken. In this paper, we present an architecture design notation based on UML's activity diagrams. The notation allows for the specification of architecture fragments and supports composition of these fragments as well as superimposition of the fragments on each other. This notation allows us to make various compositions of architecture fragments (reflecting design decision alternatives) to adapt the architecture to new requirements. We have found that our notation is very suitable for modelling separate concerns at the architectural level and for creating.

fulfilment of the requirements for the degree of Licentiate in Engineering. Contact Information: