Abstract-Object-oriented applications of significant size are often complex and therefore costly to maintain. Indeed, they rely on the concept of class which has low granularity with varied dependencies not always explicit. The component paradigm provides a projection space well-structured and of highest level for a better understanding through abstract architectural views. But it is possible to go further. It may also be the ultimate target of a complete process of re engineering. The end-to-end automation of this process is a subject on which literature has made very little attention. In this paper, we propose such a method to automatically transform an object-oriented application in an operational component-oriented application. We illustrate this method on a real Java application which is transformed in an operational OSGi application.

Abstract. During an architectural evolution of a component-based software, certain quality attributes may be weakened. This is due to the lack of an explicit definition of the links between these non-functional characteristics and the architectural decisions implementing them. In this paper, we present a solution that aims at assisting the software maintainer during an evolution activity on his demand. It requires the definition of a documentation during development, organized in the form of bindings between formal descriptions of architectural decisions and their targeted quality attributes. Through an assistance algorithm, the approach uses this documentation in order to notify the maintainer of the possible effects of architectural changes on quality requirements. We also present a prototype tool which automates our proposals. This tool and the overall approach has been experienced on a real-world software in order to validate them.

Abstract. Software systems should evolve in order to respond to changing client requirements and their evolving environments. But unfortunately, the evolution of legacy applications generates an exorbitant cost. In this paper, we propose an approach to restructure legacy objectoriented applications into component-based applications. Our approach is based on dynamic dependencies between classes to identify potential components. In this way, the composition is dictated by the context of the application to improve its evolvability. We validate our approach through the study of three legacy Java applications.

Abstract-Metamodels evolve over time, as well as other artifacts. In most cases, this evolution is performed manually by stepwise adaptation. In MDE, metamodels are described using the MOF language. Often OCL constraints are added to metamodels in order to ensure consistency of their instances (models). However, during metamodel evolution these constraints are omitted or manually rewritten, which is time consuming and error prone.We propose a tool to help the designer to make a decision on the constraints attached to a metamodel during its evolution. Thus, the tool highlights the constraints that should disappear after evolution and makes suggestions for those which need adaptation to remain consistent. For the latter case, we formally describe how the OCL constraints have to be transformed to preserve their syntactical correctness. Our adaptation rules are defined using QVT which is the OMG standard language for specifying model-to-model transformations. I. INTRODUCTION Model Driven Engineering (MDE)[1] raises the abstraction's level of software development from code to models, with a great emphasis on focusing the developer concerns on the problem domain rather than on the underlying technologies. Metamodels are the definition of abstract syntax of languages. However, structural constructions of metamodeling languages do not allow to express completely the syntax of a language (e.g. context-sensitive properties). In consequence, to get coherent models, it is necessary to add constraints expressed using the Object Constraint Language (OCL) [2]. Moreover, metamodels evolve over time like other software artifacts [3], [4], due to several reasons: to be consistent with the evolution of the application domain scope, to improve or correct the abstract syntax of the language, etc. As a consequence, these changes may break consistency of related terminal models. The risks stem from the fact that constraints attached to metamodels are either omitted or manually rewritten, which is time consuming and error prone [4], [5].To address this problem, we propose an approach in order to assist designers in constraint adaptation during a stepwise evolution [6] of a metamodel. This approach consists in identifying the impact of a change, made at the metamodel, on its associated constraints. After each modification of the

During software development, architecture decisions should be documented so that quality attributes guaranteed by these decisions and required in the software specification could be persisted. An important part of these architectural decisions is often formalized using constraint languages which differ from one stage to another in the development process. In this paper, we present a family of architectural constraint languages, called ACL. Each member of this family, called a profile, can be used to formalize architectural decisions at a given stage of the development process. An ACL profile is composed of a core constraint language, which is shared with the other profiles, and a MOF architecture metamodel. In addition to this family of languages, this paper introduces a transformation-based interpretation method of profiles and its associated tool.

It is argued that architecture comprehension and regression testing of a software system are the most expensive maintenance activities. This is mainly due to the fact that architectural choices are either not explicit, at every stage of the software development process, or not preserved from one stage to another. In this paper, we present an Architectural Constraint Language (ACL) as a means to formally describe architectural choices at all the stages. This language is based on the UML's Object Constraint Language and on a set of MOF-compliant metamodels. We also present a prototype which validates the proposed approach. It allows the evaluation of ACL expressions at two stages and ensures, by using a transformation mechanism, that the constraints stated at one stage are subsequently preserved.

Systems of Systems (SoS) encompass a group of distributed and independent systems. This class of systems requires recurrent adaptation at runtime owing to the uncertainty and variability of the runtime environment. Thus, during their execution, SoS can deviate from the initial specification, which is often a consequence of successive evolutions. This problem occurs mainly due to (a) weak communication between the SoS analysis stage and architecture stage and (b) the lack of links between the operational planning in the SoS analysis stage and systems that must be involved in the SoS architecture stage. This paper proposes a model‐based process that strengthens the links between the SoS analysis stage and the architecture stage in the wave life cycle. We ensure that the mission and role concepts for the SoS definition are sufficiently abstract to allow adaptation to the variability of the environment. This definition is translated into an abstract architecture that guides the choices of the system architect during the design and evolution stages. The proposed language is an adaptation of the Systems Modeling Language (SysML). Furthermore, we define a crowd management SoS to illustrate the process.

Component-based software engineering provides for developers the ability to easily reuse and assemble software entities to build complex software. Component-based specification of software functionality has been and is largely addressed, however this is not yet the case for what concerns software non-functionality. In this paper, we propose a new way to express component-based software non-functional documentation, and we will focus more specifically on architecture constraints which formalize parts of architecture decisions, as executable, customizable, reusable and composable building blocks represented by components. Checking of architecture constraints is provided via service invocation through ports of a special kind of components, called constraint-components. The signatures of these checking services can be defined in required interfaces of business components, to document decisions taken while designing their architecture. They can also be part of other required interfaces of constraint components, making it possible to build higher-level or more complex constraints while reusing existing ones. We present an example of implementation of constraint components using, an ADL which is introduced in this paper. Architecture constraints can then be checked on the architecture of business components at design-time using the CLACS tool support, which has been implemented as an Eclipse plugin.