VPraxis is a tool to support the evolution of Internet applications. It automates the construction of a software application’s history together with the histories of used resources. Comparing these histories enables change impact analysis and eases evolution management.
Nowadays, almost all software applications, regardless of their purpose or domain, run on the Internet. Applications such as eCommerce, social networks, telecommuting platforms and business to business market places run on the Internet. Some are so tightly coupled with the internet that without an internet connection they would not survive.
An application that runs on the internet belongs to a complex ecosystem. It uses and provides resources that compose the ecosystem. Those resources, which were as simple as pictures or HTML documents a few years ago, are now highly complex such as web services or web semantics data. Moreover, the ecosystem is becoming increasingly dynamic as resources change every day. This makes classical software development inefficient, where well-structured teams apply traditional development cycles to build all the software artifacts that compose an application.
As shown by Baskerville, classical software development is inadequate to Internet-speed software development. Traditional principles such as “reuse” or “quality” have no place in such a context. Quality, which is expressed as a requirement and validated throughout the development cycle in a traditional development process, is on the contrary, continuously negotiated with the client and subjectively validated by the users in case of Internet applications. Reuse is not even an option as software components are deprecated after just a few months of life on the Internet.
New development approaches have been proposed to face the challenges of Internet application development. For instance, agile methods propose mechanisms to deal with continuous requirements. Web frameworks such as Ruby On Rails or Zope integrate new Internet technologies. However, even if these approaches do help development, there are still few solutions to tackle evolution. This is one factor contributing to rising maintenance costs.
Mastering the evolution of an Internet application requires being aware of the evolution of the ecosystem, or at least of the evolution of the resources used by the application. This requires answers to the following questions: "How to monitor the evolution of all used resources?", "How to measure the impact of their evolutions?", "How to know when to evolve?" and "How to identify which parts of an application have to evolve?". The purpose of our research is to answer these questions in order to automate operations performed during evolution.
Figure 1: An evolving software ecosystem monitored by Praxis histories.
Our approach consists of uniformly capturing the evolution of any application and of any used resources. We base our approach at a structural level since most of the broken evolutions occur at a structural level. We propose VPraxis, an operation-based model that unifies both source code and evolution information. Within this model, the various software artifacts that compose an application or that describe a resource are described by a history. A history contains all the actions performed to create and modify software artifacts.
Having the history of an application together with the histories of the resources it uses allows for comparison of histories. For example, with the history of an Internet application and the histories of the web services it uses, we can detect that one of the proposed services has changed and an evolution of the application is therefore required. We can also analyze the history of another application that uses the same web service in order to learn how it has evolved.
We are already able to automatically compute histories. When a versioning system is available, a history can be automatically constructed by analyzing the source code it manages. We have developed a tool that automatically constructs the history of projects managed by SVN versioning systems. In our current implementation, we support Java, CSS, HTML and XML artifacts. A history contains all operations performed to edit these artifacts since the beginning of the project. We can also build a history of a used resource by browsing its description daily, as a web crawler would do. For instance, we can build the history of web services by browsing their WSDL descriptions.
We have already performed some comparisons of histories. We have based our analysis on logical rules. For instance, we have defined a logical rule specifying that any called service has to be described by the WSDL. We then provide incremental analysis that checks the rule each time the history of the application or the history of the web service is updated. If the service is no longer supported, the check of the rule reports that an evolution is needed.
As a synthesis, the goal of our approach is to support the evolution of Internet applications by monitoring changes performed to the ecosystem. We propose mechanisms to capture the evolution of software artifacts scoped to a given application. Thanks to our concept of history, we provide reactive local views of evolution. We use those local views to compute analysis, such as comparison of histories, in order to automate maintenance operation.
Xavier Blanc and Jean-Rémy Falleri
University Bordeaux, LaBRI, France