Comité de Integración y Desarrollo Fronterizo

Software evolution and ontology evolution share common grounds. Software evolution focuses on evolving the software without invalidating running systems and existing data. In ontology evolution we focus on a similar problem. In software evolution, determining the impacts of the changes on dependent modules, classes and data is the main concern. In ontology evolution, identifying inconsistencies, invalidities and impacts of changes on entities and dependent systems is the main focus.

Software evolution integrates a multidimensional aspect of a software life cycle from the inception phase to maintenance. The dimension includes system properties (what), objects of change (where), temporal properties (when) and change support (how) [Mens et al., 2002] [Buckley et al., 2005]. Software evolution needs a systematic and exhaustive description of the change and the changing artefacts [Mens & Klein, 2012]. Like schema evolution, the process of handling evolution in software is time-consuming and error-prone. The main fo- cus of software evolution is to identify the changing artefact in the software and to identify the artefacts that are affected by the change. Researchers such as [Lehman et al., 1997] [Sherriff & Williams, 2008] [Ahmad et al., 2009] focus on classifying the different com- ponents, analysing the dependency between the components and the propagation of the changes to other dependent software artefacts. [Ahmad et al., 2009] uses sets to represent relationships between components. [Sherriff & Williams, 2008] uses association clusters from change records to analyse impacts of changes. These association clusters of files indi- cate how the files are executed, tested and changed together.

Software systems that embed a software application in the real world, known as E-type systems, evolve frequently. For such systems, researchers [Lehman et al., 1997] identified different laws of software evolution. The first law is about continuing change. E-type sys- tems must continually adapt themselves to changes; otherwise they become progressively

less satisfactory. His second law further reinforces the need for software evolution, which is increasing complexity. As a program evolves, its complexity increases unless work is done to maintain or reduce it. These two laws call for a solution to handle the changes and to avoid the associated complexities.

Software change denotes a set of source files that are modified together. The reason for the change may be removal of a defect or introduction of a new feature that reflects the user’s requirement. The changes can be logical or structural changes which may affect other dependent components of the software [Wu et al., 2007]. According to the change data the authors analysed on open source products, within 8 years (1997/08/11 to 2005/09/09) they identified 40,034 logical changes from the CVS repository of GCC. The largest logical change obtained from the NetBSD system is 86,280 logical changes from 1993/03/20 to 2005/08/17. Structural changes are also presented and 19,913 changes are identified from the Koffice system from 1999/01/01 to 2004/09/15.

These figures indicate that there is a high frequency of change. It is evident that man- aging changes and determining impacts of changes is becoming a time consuming and complex task. This implies the need for software tools that deal with the evolution process of software products.

Other research in software evolution focuses on change impact analysis in software systems using empirical analysis [Arnold, 1996] [Lee et al., 2000]. Software change or soft- ware evolution has an impact on dependent systems. These impacts were analysed using dif- ferent techniques such as PathImpact, CoverageImpact and other methods [Bohner, 2002] [Orso et al., 2004] [Breech et al., 2005] [Sherriff & Williams, 2008]. The main aim of soft- ware change impact analysis is to find out which dependent components of given software are affected by a change and to take action before the new version of the software is re- leased. Reducing the time and effort of tracking and correcting the erroneous modules is one reason for conducting impact analysis prior to the implementation of the change. As there are more changes and versions in a software product, there are more impacts of these changes on the dependent software components and this needs an automated solution to reduce the impacts.

The author in [Bohner, 2002] conducts a change impact analysis on commercial-Off- The-Shelf software. He identified different reasons for software change and classifies soft- ware impacts as direct or indirect, and structural or semantic impacts. The impact analysis method uses graphs to represent dependencies between software components. He uses graphs to analyse structural and semantic impacts of changes on dependent systems. He further conducted structural analysis and semantic analysis using reachability graphs by implementing transitive closure algorithms. The work focuses on the syntactic relation- ship between software modules whereas we focus on structural and semantic changes with detailed semantics.

In [Hassan et al., 2010], the authors present a knowledge base system for change impact analysis on software architecture. They propose an architectural software component model (ASCM) on which they defined change propagation process. They use graphs to represent a software architecture description represented by ASCM. The graph is used to capture architecture elements and their relationships. The authors conduct an impact analysis using rules that define change propagation. The change propagation process uses a knowledge- base system which stimulates the impact on the software architecture and on the actual code when the associated rules are fired. Their work is similar to ours but with a significant difference in the domain and in the impact determination approach.

To deal with software change and to understand and manage the effects of the changes, different researchers conducted software change impact analysis. [Ren et al., 2004] develop a tool for change impact analysis for Java programs. The authors identify changes by com- paring two versions of a program and represent the changes as atomic changes. Using the atomic changes, they analyse the affected elements that changed their behaviour due to the atomic changes and they explain the causes of the effects. The authors use a call graph that represents methods using nodes and edges between nodes to reflect calling relation- ship between methods. Their approach starts with identifying affected tests (targets), and moves to identify affecting tests (causes). The method computes syntactic dependencies to determine the causes of the changes. Syntactic dependencies and semantic dependencies are independent of each other and are treated differently. Using syntactic and semantic de-

pendencies, they identify the impacts of the changes on the edited version. The impact of a single change when executed alone has a different impact than when it is executed as part of a composite change. However, it is not possible to apply this approach unless we have access to the original and the edited software.