Abstract-To maintain and understand large applications, it is important to know their architecture. The first problem is that unlike classes and packages, architecture is not explicitly represented in the code. The second problem is that successful applications evolve over time, so their architecture inevitably drifts. Reconstructing the architecture and checking whether it is still valid is therefore an important aid. While there is a plethora of approaches and techniques supporting architecture reconstruction, there is no comprehensive software architecture reconstruction state of the art and it is often difficult to compare the approaches. This article presents a state of the art in software architecture reconstruction approaches.

Abstract. Software developers spend most of their time modifying and maintaining existing products. This is because systems, and consequently their design, are in perpetual evolution before they die. Nevertheless, dealing with this evolution is a complex task. Before evolving a system, structural modifications are often required. The goal of this kind of modification is to make certain elements more extensible, permitting the addition of new features. However, designers are seldom able to evaluate the impact, on the whole model, of a single modification. That is, they cannot precisely verify if a change modifies the behavior of the modeled system. A possible solution for this problem is to provide designers with a set of basic transformations, which can ensure behavior preservation. These transformations, also known as refactorings, can then be used, step by step, to improve the design of the system. In this paper we present a set of refactorings and explain how they can be designed so as to preserve the behavior of a UML model. Some of these refactorings are illustrated with examples.

In many large organizations, the model transformations allowing the engineers to more or less automatically go from platformindependent models (PIM) to platform-specific models (PSM) are increasingly seen as vital assets. As tools evolve, it is critical that these transformations are not prisoners of a given CASE tool. Considering in this paper that a CASE tool can be seen as a platform for processing a model transformation, we propose to reflectively apply the MDA to itself. We propose to describe models of transformations that are CASE tool independent (platform-independent transformations or PIT) and from them to derive platform-specific transformations (PST). We show how this approach might help in reaching a consensus in the RFP on MOF QVT, including a solution for the declarative/imperative dilemma. We finally explore the consequences of this approach on the development life-cycle.