CELL: Software evolution challenge

If it is true that enterprises, organizations and society, on all levels, depend increasingly on software; it is quite true that an intrinsic characteristic of a software, representing an activity of the real world, is the need for evolving to meet new requirements.  Indeed, the software itself depends on the enterprise for which is supposed to satisfy the needs. Software evolution is often of unanticipated nature, therefore, not envisaged at analysis time. In this case, the evolution cost depends, at the same time, on the structure of the application and the desired evolution.

One of the research objectives obvious, in this case, is to propose a framework so that the unanticipated evolution is done in a consistent way and at lower cost. Guaranteeing this consistency, during successive evolutions, is a crucial problem. The developers of the initial version of an application seek through their architectural choices, more or less explicitly, obtaining certain nonfunctional external characteristics (quality attributes, as for example, maintainability, portability, availability or safety). They can wish that whole or part of them should be maintained in the future versions of the application. These external characteristics are, to some extent, invariants that should be satisfied during each evolution. One can, for example, in a preoccupation of maintainability, impose, in the original version of a software, the respect of a layered architecture. This internal property can thus, in its turn, constitute a structural invariant which one wishes the respect during evolution. Other internal properties could have as an aim to control the increase in complexity inherent in the evolutions (in a preoccupation with a preventive maintenance) of which made state the Lehman’s second law.

Having for an application constraints, specifying in a quantitative way the structural properties to respect, will:

• guarantee the preservation of certain nonfunctional external characteristics during development as well as during maintenance,
• check, in a reuse context, that an imported component answers requirements compatible with those of the host application.

These constraints, thus, offer means of certifying an application and its evolutions.

    The main goal of this project is to propose a method and support tools, to guarantee the validity of the component certificate after its evolution. That supposes to establish, during the initial development, a set of structural constraints, which should be respected during each evolution. These constraints are defined at analysis time then enriched at design and coding time.  Some of them can also come either from a software quality plan (specific to a line of products) or of the organisation quality manual (nonspecific to this product).  In this way, the constraints appeared during the development will remain applicable and explicit even at the evolution time. We call this type of constraints an evolution contract.
The awaited results are of three forms:

• A language: allowing to formally explicit the constraints governing the possible evolutions of a component. An interesting way would be to extend OCL (Object Constraint Language) language of the OMG to take into account the evolution aspects. As OCL is the description language of contracts in UML (Unified Modeling Language), this solution would enable us to use existing UML modeling tools as bases for our experimentation platform.
• Tools: allowing on one hand to realise evolution and on the other hand, to check the conformity of any evolution with respect to the contract.

The first prototype of ACE (Architectural Contract Evaluator): a tool for checking contracts for architetcural evolution is available for download. Examples are provided for better understanding the tool functionalities.

• A procedure:  describing the place of the evolution contract in the application or component life-cycle (drafting, enrichment, consistency, checking).