A semi-automated approach to adapt activity diagrams for new use cases

Information and Software Technology 57 (2015) 543–570

Contents lists available at ScienceDirect

Information and Software Technology journal homepage: www.elsevier.com/locate/infsof

A semi-automated approach to adapt activity diagrams for new use cases Samad Paydar ⇑, Mohsen Kahani Computer Engineering Dept., Ferdowsi University of Mashhad, Iran

a r t i c l e

i n f o

Article history: Received 25 July 2013 Received in revised form 15 May 2014 Accepted 8 June 2014 Available online 19 June 2014 Keywords: Model reuse Semantic web Activity diagram Use case Adaptation

a b s t r a c t Context: Web engineering methodologies generally assign a crucial role to design models. Therefore, providing a model reuse approach is very interesting since it reduces development costs and improves quality. Current works on model reuse mainly focus on retrieval of the promising reusable assets, and much less is done regarding adaptation of the retrieved assets. This research proposes a semi-automatic approach for adaptation of UML activity diagrams to new use cases. Objective: UML use case diagrams and activity diagrams are traditionally used for the brief and the detailed specification of the functional requirements. Since many web applications have similar functionalities, and hence similar functional requirements, this research proposes an approach to take a use case diagram as input and semi-automatically create corresponding activity diagrams by adapting existing activity diagrams. Method: The proposed approach includes five main components: (1) a model repository, (2) an ontology repository as a source of domain knowledge, (3) an algorithm for annotating activity diagrams, (4) a similarity metric for retrieval of similar use cases, and (5) an adaptation algorithm for creating activity diagram of a new use case from an existing activity diagram The proposed approach uses the semantic web data model as the underlying representation format. Results: The initial experiments show that the proposed approach is promising and it provides an average reuse percent of 76%. However, it has still some weaknesses like being much dependent on the quality of the model repository and having low tolerance in case of inconsistency in the model repository. Conclusion: Enabling model reuse in the early stages of a model based development approach is very important in reducing development costs. This paper proposes a semi-automatic approach to reuse activity diagrams through their adaptation for new use cases. The approach is demonstrated to be promising although it has still some limitations. Ó 2014 Elsevier B.V. All rights reserved.

1. Introduction Web engineering is a software engineering discipline focused on the systematic and quantifiable methods for developing and maintaining web based systems [46]. It has emerged since the traditional software engineering practices are not adequate for handling specific characteristics, complexities and requirements of web applications [45]. Different web engineering methodologies are proposed during the last two decades. They are mostly evolved to follow the Model Driven Development (MDD) [42] approach [1]. In other words, the

⇑ Corresponding author. Address: Computer Engineering Dept., Ferdowsi University of Mashhad, Azadi Square, Mashhad, Iran. Tel.: +98 915 3090401; fax: +98 511 8788131. E-mail address: [email protected] (S. Paydar). http://dx.doi.org/10.1016/j.infsof.2014.06.007 0950-5849/Ó 2014 Elsevier B.V. All rights reserved.

designer is required to create initial models of the web application in a well-defined format, and then these models are automatically or semi-automatically transformed to other types of models or even to the final executables. Despite their benefits, these modeldriven approaches have the problem that development of each new web application implies creating a probably large set of models from scratch. The main solution to this problem is model reuse, i.e. reusing models of similar existing web applications for creating models of the new one. Among the different types of models, functional requirements models are of much importance since they specify the fundamental behaviors that should be provided by the system [66]. A traditional way of specifying functional requirements is to use UML use case diagram for brief specification, and UML activity diagrams for detailed description of each use case [59]. While creating the brief specification is simple, creating the detailed description of each use

544

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

case is time consuming. In this paper, a semi-automatic approach is proposed for reusing functional requirements models. The proposed approach enables creating the activity diagram of a new use case by reusing models of similar web applications. More specifically, the new activity diagram is created by adapting the activity diagram associated with an existing use case which is very similar to the new use case. The proposed approach includes five major components: (1) a model repository which contains models of existing web applications, (2) an ontology repository including ontologies of different domains, (3) an annotation algorithm which is executed on the activity diagrams of the model repository to make them ready for later reuse, (4) a use case similarity metric which is used to retrieve from the model repository the most similar use cases to the input use case, and (5) an adaptation algorithm which is responsible for creating corresponding activity diagram of a new use case from the annotated activity diagram of a similar use case. From a process point of view, the proposed approach includes two major steps. The first step includes preparation of the model repository, annotation of the repository models, and building the ontology repository. In the second step, the proposed similarity metric and the adaptation algorithm are used to realize model reuse. To the best of our knowledge, current paper is the first work which uses the UML use case diagrams as the input of a model reuse approach, and bridges between use cases and activity diagrams. Existing reuse approaches like [57] take also the detailed description of the use case whether in terms of UML activity diagram or other modeling technique, e.g. structured scenarios. Since use case diagrams are very simple and concise, some level of background and domain knowledge is required to create their corresponding activity diagrams. Current paper proposes to use a model repository and an ontology repository to address this requirement. A prototype of the proposed approach is implemented and the initial experiments demonstrate that it is sound and promising, although more work is still needed to fully achieve the potentials. The paper is organized as follows: a brief literature review is presented in Section 2. The proposed approach is introduced in Section 3, and its experimental evaluation is discussed in Section 4. Validity of the experiments along with the current limitations and future works are discussed in Section 5. Finally, Section 6 concludes the paper.

2. Related work The proposed approach is related to different fields like model reuse, automatic model creation, and web engineering. In this section, a brief review of these fields is provided.

2.1. Model reuse Software reuse focuses on the use of existing software assets to create new software instances, with the goal of improving software quality and productivity [23,43,44]. Reuse at source code level has long been explored by the researchers and used by the practitioners. However, reuse at design level is more challenging due to different reasons like the multi-dimensional nature of the modeling process, the variety of models to be designed, and the multiple aspects which should be modeled [2,50]. On the other hand, providing reuse at design level has considerable effect on the development effort reduction and also on the quality of the products [56,54,13]. Especially, importance of starting the reuse process from the use case diagrams has been acknowledged [29].

There are a number of works focusing on model reuse. In some works, a general model search engine is proposed. For instance, Moogle [41] is a general purpose model search engine capable of indexing and searching UML models. It supports keyword-based as well as faceted search. In [12] a method is proposed for searching models using information retrieval techniques. Another model search engine is also proposed in [47]. Kling et al. [33] propose MoScript, a Domain Specific Language (DSL) through which users can store, retrieve, and manipulate models using a query based approach. The goal is to provide an efficient facility for reusing models or model fragments. In [10], graph based techniques are used for search and retrieval of models. Another group of works focus on reuse of specific types of UML models. In [82], a review of the works on reusing UML models is provided and four categories are identified for techniques used to compare a query artifact with artifacts in the repository. These include techniques based on (1) graph matching algorithms [83– 85], (2) ontology-based similarity measurement [50,85], (3) Case Based Reasoning (CBR) [87,88], and (4) information retrieval methods (e.g. classification, clustering, vector space similarity) [89,90,2]. As an example, Robles et al. [50] propose an ontology-based approach for retrieval of UML class diagrams. This approach uses an application ontology for measuring similarity of class diagrams, and also a domain ontology for query expansion. Another approach for reusing class diagrams is proposed in [91]. While about half of the UML diagram types are not yet considered for reuse, UML class diagrams, sequence diagrams and use case diagrams are the three kinds of diagrams that are considered the most in the existing works [82]. Among the UML models, reuse of use cases is very appealing, since they play an important role in the requirements specification phase and are created in the earliest steps of the development life cycle. [29,30]. The existing works on use case based reuse can be classified to two groups. In the first group, textual descriptions of the use cases are reused. For instance, a method is proposed in [92] for retrieval of use case descriptions based on their structure. This method identifies 12 features for each use case description, e.g. use case name, and the names of the use cases which it generalizes. Further, textual similarity measures and traditional information retrieval techniques are employed to retrieve use case descriptions. As another example, in [89], a method is introduced for retrieval of UML use case descriptions based on similarity of their corresponding sequences of event flows. It also employs manual clustering to organize existing use cases, in order to reduce complexity of comparison and retrieval step. Another approach for reusing use case descriptions is also presented in [93]. In the second group, reuse of use case diagrams in their diagrammatic format is addressed. Srisura and Daengdej [94] propose a Case-Based Reasoning (CBR) approach for retrieval of UML use case diagrams. The main component of their approach is a similarity metric for comparing use case diagrams, based on their textual and relational similarity. As another example, an approach is proposed in [86] for reusing use case diagrams. This approach employs simple keyword-based search on the ontological representation of the use case diagrams. While most of the works on reusing use cases belong to the first group [82], but importance of reusing use cases in their diagrammatic form, not their textual description, is also highlighted in the literature [94]. Considering the fact that a complete process for model reuse is expected to support representation, retrieval, adaptation, and incorporation [95] of the models, review of the existing works demonstrates that most works address only the first two activities. In other words, most of the existing works only support retrieval of the artifacts which are promising for reuse, but they do not provide a specific facility for actually reusing the retrieved artifacts for the

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

545

context of the new problem. This means that the adaptation phase within which the reuse is actually performed is left to the user. A novelty of the current paper is that it specifically addresses adaptation of the retrieved models through adaptation of an existing activity diagram for a new use case. Further, the proposed approach is different with existing use case based reuse methods because it takes as input only the use case diagram of the new web application and not the textual description of the use cases. This has the benefit that the cost of applying this approach is reduced.

2.2. Automatic model creation Despite the important role of models in software development lifecycle, it is both difficult and time-consuming to manually create precise and valid models, especially for large web applications. There are some works which focus on automatic model creation, whether by extracting the model from textual specifications of the requirements, or by transforming some other types of models, or by a mixture of the two techniques. For instance, the approach proposed in [27] takes a textual requirements specification as input and uses Natural Language Processing (NLP) techniques to translate it to a special kind of graph. This graph is then used to generate the corresponding UML diagrams (e.g. class or use case diagram). In [38], domain models (in terms of UML class diagrams) are extracted from natural language textual specifications of the system. It is stated that some level of common-sense knowledge is required in order for machines to be able to overcome ambiguities of natural language texts. An ontology, specifically the RCyc ontology,1 is used to provide such knowledge. In [51] also a method is introduced for producing domain models from use cases specified in a controlled natural language grammar. Due to importance of use case modeling as a traditional approach for software requirements specification [29,19,8], many researchers have worked on approaches for automatic extraction of other types of models from the use case models, for instance [5,40,63,65,24]. A review of some of these works is presented in [62]. In [64], the authors present a set of well-defined rules that restricts the way users specify the textual specification of use cases. Enforcement of these restrictions reduces the possible ambiguity of the textual specifications, hence provides more opportunity for derivation of analysis models through NLP or other techniques. The authors have evaluated their rules and concluded that while they are easy to understand and use, they also improve the quality of the derived models. Another approach to automatic model creation is Model-Driven Development (MDD) [42] which uses model transformation techniques as a primitive [53,36]. Textual specifications are not much interesting from the point of view of MDD, due to their ambiguities and the lack of precision and formality [60]. In [6], the authors discuss the importance of visual modeling in model-driven architecture. In [31] a transformation mechanism is proposed for synthesizing UML activity diagrams from scenario-based specifications which are modeled as UML sequence diagrams. The transformation is performed based on a set of rules that define the mapping for a number of predefined patterns in the sequence diagrams. An essential component in most of these works is a set of rules for transforming models of the source type to models of the target type. In Fig. 1 (top) the traditional approach followed in these works is shown. 1

CyCorp. ResearchCyc. http://research.cyc.com.

Fig. 1. Traditional approach of automatic model creation (top), the proposed approach of this paper (bottom).

The proposed approach of the current paper seeks to get use case diagrams as input and generate activity diagrams as output, and therefore it performs some kind of automatic model creation. However, since use case diagrams and activity diagrams are at very different levels of abstraction, providing a rule set for the transforming use cases to activity diagrams is very challenging, if possible. To tackle with this problem, the proposed approach employs model reuse. As shown in Fig. 1 (bottom), this approach bridges the input and output using three links numbered in this figure. The first link is established by a proposed use case similarity metric which identifies, from the model repository, the most similar use case to the input use case. Since the associated activity diagram of this use case already exists in the model repository, the second link is explicitly established in the repository. The third link is established by the proposed adaptation algorithm which adapts the repository activity diagram to create the new activity diagram. This approach has eliminated the above challenge and actually no transformation rules between two different model spaces are defined in the proposed approach. 2.3. Semantic web enabled software engineering Semantic web technologies enable representing data in a way that semantic of data is simultaneously represented with the data. This enables machines to perform more complex processing on semantic web data. Due to the benefits of the semantic web technologies, there are many works which use the semantic web technologies in software engineering activities [7,14,25]. Despite the large number of these works, there are two main themes: 1. Using the semantic web technologies as a data model or representation format. The formality, inference capability, and machine-understandability provided by this ontology-based data model provide effective mechanisms for accessing, analyzing and retrieving data. For instance, it is shown in [58] that by representing information of source code in the semantic web data model, the cost and complexity of source code analysis can be considerably reduced. Another examples include integrating data of different types of software artifacts [28], improving software components search [61,3,4,26], source code search [20,32], automatic design pattern detection [49] and configuration management [55]. 2. Using the semantic web as a source of background or domain knowledge. There are different sources on the web which publish data based on the semantic web data model. These sources,

546

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

e.g. ontology repositories or Linked Data [9] sources like DBpedia [11], can be considered as a source of machine-processable knowledge. This knowledge can be used in software engineering for different purposes like automating a process [16,38], or eliminating natural language ambiguities [15,39]. Since any reuse method involves search and retrieval of promising assets from a repository, if the repository assets are represented based on the semantic web data model, the quality of search and retrieval can be improved [50]. In [23], different properties like availability, searchability and understandability are mentioned for a repository asset in order to enable its reuse. Our point of view is that if the repository assets are represented based on the semantic web data model, then these properties are improved. In addition, this data model supports automatic reasoning over data, the facility which its necessity is acknowledged in the reuse research domain [23,3,4]. The approach proposed in this paper follows both themes mentioned above. It uses the semantic web data model for representing information of the existing models. Further, it uses a repository of ontologies collected from the semantic web. This ontology repository is used in the proposed approach for providing the required information which is not explicitly specified in the user’s input. 2.4. Web engineering Web engineering is a software engineering discipline which specifically deals with the systematic design and development of web based systems [46]. Different web engineering methodologies are introduced during the last decade. Based on the modeling notations and methods, these methodologies can be classified to different groups [73]: data-oriented methodologies like WebML [17] and Hera [74] which are rooted in the Entity Relationship (ER) model known in the field of data bases, hypertext-oriented methodologies like WSDM [18] and HDM-lite [75] which put an emphasis on the hypertext nature of the web applications, object-oriented methodologies like OOHDM [52] and UWE [34,35] which are mainly based on UML, and software-oriented methodologies like WAE and WAE2 [76] which concentrate on the use of traditional solution in the software engineering domain. In [59], the authors have surveyed nine Model-Driven Web Engineering (MDWE) methods that explicitly consider requirements modeling in the development process. The goal is to identify what techniques they provide for the specification of data, functional and navigational requirements, the extent of their capabilities for specifying these requirements, and how they use these requirements models in a MDD way? As this survey shows, UWE [34] receives good score from both perspectives of the requirement specification expressiveness and MDD support. NDT [21] is also an interesting method which has many commonalities with UWE, but the extensive use of various formatted templates, which are not easy to complete, increases the complexity of modeling large web applications. As acknowledged by this survey, using use cases and activity diagrams is very common for specification of the functional requirements in web engineering methods. UWE has the advantage that its modeling notation is completely based on UML, while its design process is based on Model Driven Architecture (MDA) [48]. Further, continuous researches are being conducted to improve UWE. Recently, UWE has introduced a UML profile named WebRE (Web REquirements) for the purpose of requirement specification [22]. This profile is based on the use of use case diagrams along with activity diagrams, correspondingly for brief and detailed specification of requirements. UWE requirements models are used through a model to model transformation to create the initial

version of the navigational and content models. These models, after necessary refinement, can automatically be transformed to the final. While the proposed approach of the current paper is general and it is not limited to a specific web engineering methodology, it is potentially more interesting if considered in conjunction with UWE methodology. The proposed approach takes the brief specification of the requirements in terms of use case diagram and generates the detailed description of the requirements in terms of UML activity diagrams. On the other hand, UWE supports automatic derivation of content and navigational models from the requirements models, i.e. use case diagrams and activity diagrams [37], therefore the proposed approach can be used in conjunction with UWE to provide a high level of automation in creating models. 3. The proposed approach In this section, first, the underlying ideas of the current work and the corresponding motivations are described. Then, the steps of the proposed approach are introduced in details. 3.1. Background and motivation The proposed approach is based on the following ideas: 1. Different web applications have similar functionalities, and hence similar functional requirements [45]. 2. Modeling functional requirements is usually performed at the earliest steps of development [59]. 3. It is possible to derive, to some extent, other types of models from the functional requirements models [37]. 4. Using UML use case diagrams and activity diagrams is a traditional method for brief and detailed description of the functional requirements [59]. 5. It is possible to take the brief description of the functional requirements of a new web application in terms of UML use case diagram, and generate the draft of the corresponding detailed description in terms of UML activity diagrams, by reusing functional requirements models of existing web applications. While the first four ideas are not novel, the fifth one is. The main challenge to realize this idea is the lack of required information in the input. Each use case diagram includes a set of use cases, and each use case declares a proposed behavior of the subject system from a high level of abstraction. This behavior involves manipulating some concepts. Details of these concepts (i.e. their attributes and relationships) are usually described within a UML class diagram. In order to create an activity diagram for each use case in the new use case diagram, it is required to have knowledge about details of the corresponding behavior and the associated concepts. The current paper proposes to address this challenge by utilizing two sources for providing the required information: 1. A model repository which contains models of existing web applications. 2. An ontology repository which is populated with ontologies retrieved from the semantic web or the ones built manually. To create an activity diagram for a new use case, the detail of the corresponding behavior is expected to be retrieved from the model repository, since it possibly includes similar activity diagrams that describe the same behavior. Further, details of the corresponding concepts are also expected to be retrieved from the model repository since it might include a class diagram describing those concepts. If such a class diagram does not exist in the model

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

repository, then the ontology repository is used to search for the required information. The idea of using ontologies from the semantic web to collect information about concepts is based on the implicit assumption that the kind of information provided by UML class diagrams generally can be retrieved from the semantic web. The fact that many web applications have similar functional requirements provides good potential for the proposed reuse approach. If this approach is successful, then it will provide interesting advantages which are in fact the motivations of the current work:  The development cost and complexity is reduced. The user can give a use case diagram to the proposed approach and take the drafts of the required activity diagrams. This is much more cost effective than creating each activity diagram manually and from scratch.  Reuse is provided at the very early stages of the development lifecycle.  It is possible to combine the proposed approach with other existing approaches to provide a high level of automation, by using output of the proposed approach as input of other existing techniques. For instance, the method described in [37] takes as input the functional requirements in terms of use cases and activity diagrams, and generates as output the drafts of the design models. If this method is pipelined with the proposed approach, then it is possible to start from a use case diagram and automatically create the design models.  A contribution is made to the field of semantic web enabled software engineering. Although there are many works that use the semantic web technologies like ontologies, reasoners or RDF data model in software engineering activities, but there are very few works, e.g. [38,39], which focus on using the semantic web as a source of domain or background knowledge in software engineering. If evaluations demonstrate that the idea of populating the ontology repository from the semantic web has advantaged the proposed approach, then it becomes more evident that the semantic web can be considered as a conceptual space which is helpful in automating software design activities. 3.2. Basic definitions Since use cases play an important role in the proposed approach, it is required to describe in more details how use cases are treated in this approach. In this paper, each use case UCi is considered to be a tuple of the form

UC i ¼ fUCDi ; namei ; Si ; Bi ; C i ; Ai g where UCDi is the use case diagram containing UCi, namei is the name of UCi, Si is the name of the subject system to which UCi belongs, Bi is the set of declared behaviors of UCi, Ci = {C | behavior of UCi involves manipulating instances of concept C}, Ai is a set containing names of the actors associated with UCi. Having a use case UCi and the associated use case diagram UCDi which belong to the system Si, it is easy to determine namei and Ai, since they are explicitly specified in UCDi. However, identification of Bi and Ci is not trivial. The idea of this paper is that if a use case is properly named, then its name must reveal its behavior and also associated concepts. As a result, a simple algorithm is proposed for this purpose. This algorithm is described below. 3.2.1. Behavior/concept detection algorithm The proposed algorithm for detecting behaviors and concepts of a use case UCi from its name namei works in the following way. First, namei is converted to an expression exp by separating its tokens with a space. Then, exp is changed to lower case, and a salt

547

is added to its beginning. Finally, exp is given to a Part Of Speech (POS) tagger, and the words after the salt which are assigned a verb tag are selected as Bi, and the words after the salt which have a noun tag are selected as Ci. Since names of the use cases are usually very short expressions and not complete sentences, POS tagging on the name of a use case might fail in correctly assigning word tags. For instance, for a use case named ‘search contacts’, the Stanford POS Tagger2 assigns a name tag to both words ‘search’ and ‘contacts’. The salt string is actually used to address this issue by making the use case name more similar to a complete sentence. For instance, for the use case mentioned above, if salt = ‘I want to’, then the resulting expression exp is ’I want to search contacts’. If this string is given to the POS tagger, a verb tag is assigned to the word ‘search’ and a noun tag is assigned to the word ‘contacts’, which is a correct assignment. In order to use the proposed algorithm, it is required to once set an appropriate value for salt. This must be performed experimentally by testing different intuitively potential values to identify behaviors of the use cases which are stored in the model repository, and selecting the salt which has the best results. Such an experiment is described in Section 4.3. Next, the detailed description of the proposed approach is presented. 3.3. Detailed description The proposed approach includes two major steps. In the first step, the model repository and the ontology repository are prepared and in the second step, these repositories are used to provide reuse based on input use cases. Next, these steps are described in details. 3.3.1. Preparation of the model repository Model repository is a repository which contains models of existing web applications. For each existing web application, the model repository is expected to include a use case diagram with n use cases, an activity diagram for each of these use cases, and a class diagram for the whole web application. Preparation of the model repository involves a process which is executed for every web application that its models are being added to the repository. This process includes three steps: 1. Model validation: the input model is checked to identify its potential quality problems. 2. Model transformation: the input model is given to a parser to transform its information to the semantic web data model. Result of this transformation which is a set of RDF triples is stored in the model repository. 3. Activity diagram annotation: a proposed annotation algorithm (discussed in Section 3.3.1) is executed on the activity diagrams of the input model and the resulting annotations are added to the repository in terms of new RDF triples. Next, each of these steps is described in more details. 3.3.1.1. Model validation. The model repository plays an essential role in the proposed approach since it is a source of reusable assets. Therefore, it is reasonable to perform some validation on the models which are being included in the model repository. The model validation step is aimed at checking an input model to detect problematic issues to which the proposed approach is sensitive. It involves the following two steps: 2

http://nlp.stanford.edu/software/tagger.shtml.

548

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

1. The input model is checked to see whether each use case has at least one declared behavior. This is performed by running the proposed behavior/concept detection algorithm on the use case. The idea behind this checking is that when existing models are being reused, a use case similarity metric is used to retrieve similar use cases from the model repository. This metric assign an important weight to similarity of the behaviors of two use cases. Consequently, if a use case has no behavior, then its similarity cannot be effectively computed by the proposed metric, and therefore it cannot contribute to model reuse. 2. For each use case name, and for each label in an activity diagram in the input model, the name or the label is first tokenized and then:  each token is spell-checked. This is intended to eliminate the problems caused by misspellings, unintelligible abbreviations or dummy names in the models, since these issues reduce quality of the proposed annotation algorithm and also the similarity metric.  each token is given to a stemmer to check whether it can be stemmed. This check is included since the proposed similarity metric uses stemming when comparing two use cases. It is important to note that some stemmer algorithms, like Porter stemmer [101], have the property that for each input token, whether a correct token or an erroneous one, they produce some output. This is not appropriate for this step. The stemmer algorithm should have the ability to distinguish correct tokens from incorrect tokens. We have used a stemmer algorithm in the experiments which has the nice property that for any input token, if it is stemmed, then the output of stemming exists in WordNet lexicon [96]. The validation method is designed to be non-obtrusive in the sense that any detected issue along with possible suggestions is reported to the repository manager who is preparing the model repository. The repository manager then can decide whether to correct the reported issue or to ignore it. For instance, a misspelled token is reported along with the suggested words, and the repository manager can select the correct word, or ignore the issue, or ask the spell checker to add the corresponding word to its dictionary. The latter case actually enables incremental improvement of the spell checker. 3.3.1.2. Model transformation. After a model file is passed the validation step, it is given as input to a model transformation step. This transformation creates a semantic web based representation of the model information. Three main components are involved in this step: 1. UML Ontology. An OWL ontology is developed which defines the main concepts and relationships associated with UML use cases, class diagrams and activity diagrams. This is based on the standard definitions published in [67]. 2. Model Parser. A parser is developed which takes a XMI file containing a number of UML models, and generates the semantic representation of the information of the models. This representation is in terms of a set of RDF triples expressed based on the terminology provided by the underlying UML ontology. 3. Model Repository. The RDF triples created by the model parser are stored in the model repository. The main functionalities of this repository are storing RDF triples, executing SPARQL queries on the stored triples and returning the query results. By the use of ontologies in the representation layer, it is possible to provide some level of automatic inference over data. This benefit is realized in the implementation of the parser. Instead of hardcoding all the required functionalities of the parser, some of these

functionalities are implemented simply by declaring inference rules in a textual file. After the parser has created RDF triples corresponding to a model file, it loads these rules to automatically perform reasoning over the created triples and potentially infer new triples. This improves flexibility of the implementation, because it is easy to modify functionality of the parser by manipulating the corresponding rules. Currently, the model parser uses 18 inference rules, two of which are shown in Fig. 2. Briefly speaking, the first rule states that a class inherits attributes of its superclasses, and the second rule means that if an actor uses a use case UC1, then he can also use the use cases that extend UC1. 3.3.1.3. Activity diagram annotation. The idea behind activity diagram annotation is that while the activity diagram of a use case describes details of the behavior of that use case, it also contains some references to domain entities of the corresponding web application. Consequently, if these references are explicitly specified, then it is possible to adapt that activity diagram for a new use case which has a similar behavior, by updating these references to appropriate entities from the new web application. This is based on the assumption that if two use cases have similar behavior, their corresponding activity diagrams can be similar. The goal of the annotation algorithm is to identify and explicitly specify the references from the activity diagram to the domain entities. Here, by domain entities it is meant the classes defined in the class diagram, their attributes, and the actors in the use case diagram. The proposed annotation algorithm is presented as pseudo code in Fig. 3. It takes as input an activity diagram AD (from the model repository) which belongs to a web application WA, along with the associated class diagram CD and the corresponding use case diagram UCD. The output of the algorithm is a list of annotations for AD. The algorithm starts by creating a list named entities which includes classes declared in CD, attributes declared in these classes, and actors declared in UCD (lines 1–4). Then it initializes a list named labels which contains all the labels of AD (line 5). Further, annotations is initialized with an empty list (line 6). Then for each label L in list labels, the algorithm creates a list of annotations annotationsL (lines 7–23). To do so, it first tokenizes label L, and then searches different N-grams of the tokens in the list entities to see if there is any entity (i.e. class, attribute or actor) whose name equals with the N-gram. For each matching entity, an annotation is created and added to annotationsL (lines 14–19). Each annotation has four attributes:  Source: identifier of the activity diagram element to which label L belongs.  Target: identifier of the entity that its name is matched with the N-gram.  Text: the matched N-gram.  Type: a numeric value which indicates type of the annotation. After creating all possible annotations for label L, if there is more than one annotation in annotationsL, an annotation resolution algorithm is executed to decide which annotations are more appropriate and which ones can be removed (lines 24–26). Then, annotations in annotationsL are added to annotations list which is finally returned as the output of the algorithm. Next, two issues about the proposed algorithm are described: annotation types and annotation resolution algorithm. 3.3.1.4. Annotation types. The proposed annotation algorithm can produce different annotations for an input activity diagram. These annotations differ in the way they are processed later by the proposed adaptation algorithm. Some annotations are more interesting from the adaptation point of view, i.e. they are more easily

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

549

[rule1: (?subclass rdf:type uml2rdf:Class), (?generalization rdf:type uml2rdf:Generalization), (?generalization uml2rdf:hasSpecific ?subclass), (?generalization uml2rdf:hasGeneral ?superclass), (?superclass rdf:type uml2rdf:Class), (?superclass uml2rdf:containsAttribute ?attribute) -> (?subclass uml2rdf:containsAttribute ?attribute)] [rule2: (?extend rdf:type uml2rdf:Extend), (?extend uml2rdf:extendedCase ?uc1), (?extend uml2rdf:extension ?uc2), (?actor uml2rdf:usesUseCase ?uc1) -> (?actor uml2rdf:usesUseCase ?uc2)] Fig. 2. Sample inference rules used by the model parser.

Input: AD: an activity diagram from web application WA CD: class diagram associated with WA UCD: use case diagram associated with WA Output: annotations: a list of annotations created for AD Algorithm 1. classes = list of the classes declared in CD 2. attributes = list of the attributes of the classes declared in CD 3. actors = list of the actors declared in UCD 4. entities = {classes, attributes, actors} 5. labels = list of the labels declared in AD 6. annotations = an empty list 7. foreach label L in labels { 8. annotationsL = an empty list 9. tokens = list of the tokens of L 10. for N=1 to MAX_NGRAM_LENGTH { 11. foreach N-gram text from tokens list { 12. foreach entity ent in entities { 13. if(ent.name == text) { 14. annotL = new Annotation 15. annotL.source = identifier of the element to which label L belongs 16. annotL.target = ent.identifier 17. annotL.text = text 18. annotL.type = determine annotation type 19. annotationsL.add(annotL) 20. } 21. } 22. } 23. } 24. if(annotationsL.size > 1) { 25. annotationsL = annotation_resolution(annotations L) 26. } 27. annotations.add(annotationsL) 28. } 29. return annotations Fig. 3. Pseudo code of the proposed annotation algorithm.

adapted, but some annotations are less interesting and their adaptation is more challenging. Based on this point of view, currently, seven different types of annotations are identified which are divided to two main groups: connected annotations, and disconnected annotations. A connected annotation of an activity diagram AD can be considered as an explicit path from AD to its corresponding use case UC. A disconnected annotation does not establish such a connection. Five types of connected annotations and two types of disconnected annotations are described below. For each type, a simple example is provided. In all the examples it is assumed that use case UC is named ‘Create Account’ and hence its concept set is {‘Account’}. Further, it is assumed that there is a class named ‘Account’ in the corresponding class diagram CD. Connected annotation types are: 1. Annotation Type 1: AD contains a label L which includes name of a class CL (from the class diagram), and this class is matched with a concept C in the concept set of UC. This annotation can be seen as a path of the form [AD ? L ? CL ? C ? UC]. For

instance, assume that AD includes a label L = ‘new Account’. Since L includes name of the class ‘Account’ which is matched with a concept C = ‘Account’ from the concept set of UC, an annotation of type 1 is created with class CL as its target. 2. Annotation Type 2: AD contains a label L which includes name of an attribute A from class CL, and this class is matched with a concept C in the concept set of UC. This annotation is considered as a path of the form [AD ? L ? A ? CL ? C ? UC]. As an example, assume that AD includes a label L = ‘enter username’, and class CL = ‘Account’ has an attribute A = ‘username’. In this case, an annotation of type 2 is created which its target is attribute A. 3. Annotation Type 3: AD contains a label L which includes name of a class CL, and this class has a direct or indirect relationship (e.g. generalization) with another class CL’ from the class diagram, and class CL’ is matched with a concept C in the concept set of UC. This annotation can be seen as a path of the form [AD ? L ? CL ? CL0 ? C ? UC]. For instance, assume that AD includes a label L = ‘notify user’, and there is a class CL = ‘User’ which has an association with class CL0 = ‘Account’. Here, an annotation of type 3 is created and its target is class CL.

550

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

4. Annotation Type 4: AD contains a label L which includes name of an attribute A from a class CL, and this class has a direct or indirect relationship with another class CL0 , and class CL0 is matched with a concept C in the concept set of UC. This annotation is considered as a path of the form [AD ? L ? A ? CL ? CL0 ? C ? UC]. As an example, assume that AD includes a label L = ‘gender == male’, and there is a class CL = ‘User’ which has an attribute named ‘gender’ and it has an association with class CL0 = ‘Account’. In this case, an annotation of type 4 is created which its target is attribute A. 5. Annotation Type 5: AD contains a label L which includes name of an actor AC who uses UC. This annotation is considered as a path of the form [AD ? L ? AC ? UC]. For instance, assume that AD includes a label L = ‘send notification to admin’, and there is an actor AC named ‘admin’ who is associated with UC, i.e. uses UC. In this case, an annotation of type 5 is created with actor AC as its target. In addition to the connected annotation types, two types of disconnected annotations that can be produced by the algorithm are: 1. Annotation Type 6: AD contains a label L which includes name of a class CL, and this class is not matched with any of the concepts in the concept set of UC. Further, there is no class CL0 so that CL has a relationship to CL0 and CL0 is matched with a concept in the concept set of UC. For instance, if label L is ‘show CAPTCHA’ and there is a class CL = ‘CAPTCHA’, label L includes name of class CL, but this class does not match with any concept from the concept set of UC. Now, if there is no relationship (in the class diagram CD) between class CL = ‘CAPTCHA’ and a class CL0 which is matched with a concept C of UC, then an annotation of type 6 is created which its target is class CL. It is clear that this annotation does not establish a path between AD and UC. 2. Annotation Type 7: AD contains a label L which includes name of an attribute A from a class CL, and this class is not matched with any of the concepts in the concept set of UC. Further, there is no class CL0 so that CL has a relationship with CL0 and CL0 is matched with a concept in the concept set of UC. For instance, assume that label L is ‘complexity_level < 5’ and there is a class CL = ‘CAPTCHA’ which has an attribute A = ‘complexity_level’. Further, there is no relationship between class CL and any class CL0 which is matched with a concept from the concept set of UC. Here, an annotation of type 7 is created with attribute A as its target.

3.3.1.5. Annotation resolution algorithm. While it is probable that no annotation is created for a label L, it is also possible that more than one annotation is created for it. For instance, for a label ‘ShowAddressBook’, it is possible that the 2-gram ‘AddressBook’ is matched with the name of the class ‘AddressBook’, and also the 1-gram ‘Address’ is matched with the name of an attribute ‘address’ from the class ‘User’. If a human was responsible for selecting the most appropriate annotation, he would probably first identify the context of activity diagram AD or label L by determining the main concept that AD or L deals with. Then he would compare the candidate annotations to see which one is more related to the context. The proposed resolution algorithm is based on a similar idea. It determines which annotation has more priority and which ones can be removed by identifying the annotation which is closer to the context of AD or L. Input of the algorithm is a set of annotations for a label L, and its output is a non-empty subset of the input annotations. The

algorithm first assigns a priority level of ‘high’, ‘medium’ or ‘low’ to each input annotation based on a set of rules. Then it applies another set of filtering rules to remove less appropriate annotations. The annotations that survive this filtering are the output of the algorithm. The priority levels are assigned based on the following rules: 1. If target of the annotation is an attribute of class CL, and name of this class is included in label L, then priority level of the annotation is ‘high’. This is based on the idea that label L itself provides references to the context by explicitly specifying name of class CL. 2. If target of the annotation is a class CL or one of its attributes, or an actor AC, then if the name of class CL or actor AC is matched with a concept from the concept set of UC, then this annotation is assigned a ‘medium’ priority level. The idea is that name of a use case reflects its context by explicitly specifying the main concepts that the associated activity diagram manipulates. 3. If the annotation is not matched with the rules number 1 and 2, then its priority level is ‘low’. After assigning priority levels of all the annotations of label L, then each annotation is checked to see if it should be removed. An annotation ANNOTi is removed if and only if at least one of the following conditions is met: 1. There is another annotation ANNOTj so that Textj = Texti and PLj is higher than PLi, where PLj and PLi are correspondingly priority levels of ANNOTi and ANNOTj. 2. There is another annotation ANNOTj so that Textj includes Texti. 3. There is another annotation ANNOTj so that Textj = Texti, and Targetj is a class while Targeti is an actor. In order to make the resolution algorithm and its rules more clear, some examples are provided in Section 4.5, where experimental evaluation of this algorithm is discussed. An important point about the resolution algorithm is that it still may leave more than one annotation for a label. As will be discussed in the next section, annotations play an essential role in the proposed adaptation algorithm. Therefore, having more than one annotation for a label L provides more chance for adaptation of L, because it is more probable that at least one of its annotations can be adapted. On the other hand, multiple annotations of a label may lead to different adaptations for that label, and this reduces certainty of the proposed adaptation algorithm. Consequently, the number of annotations of a label is better to have a small upper value like 2 or 3. The evaluation results presented in Section 4.5 demonstrate that the proposed resolution algorithm meets this requirement. 3.3.2. Preparation of the ontology repository The ontology repository is a repository which contains ontologies of different application domains. Its role is providing formal specification of the conceptualization of different domains in an application independent format. Building the ontology repository is a manual activity that implies searching for ontologies of the domains of interest, evaluating these ontologies, and selecting the best candidates for populating the repository. In case that the required ontologies are not found, they need to be created manually. By domains of interest, it is meant the domains for which the proposed approach is expected to provide reuse. In other words, if the proposed approach is deployed in a software organization, then the ontology repository should contain ontologies of

551

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

the domains for which that organization is building web applications. There are different potential sources for finding an ontology of a specific domain. In addition to the general search engines like Google, there are also some semantic search engines like Swoogle,3 Watson,4 FalconS5 and Sindice6 which facilitate ontology search. Further, there are large ontologies like RCyc7 which provide knowledge of different domains in a machine processable format. Finally, with the growth of the amount of data in linked data sources like DBpedia8 or Linking Open Data (LOD)9 cloud, the semantic web data sources seem to be promising for finding the required ontologies. After candidate ontologies are found, it is required to analyze and evaluate them for selecting the most appropriate ones. Different approaches to ontology evaluation are proposed in the literature. In some methods like OntoClean [77] and CleanONTO [78], complex theoretical foundation is used to detect inconsistencies and logical conflicts in the taxonomic relationships of ontologies. There are also some metric-based approaches like OntoMeter [79], Pan-Onto-Eval [80] or AKTiveRank [81] which are easier to apply. Current paper does not propose a specific evaluation method and this is left to the person or party who is building the ontology repository. However, our point of view is that using metrics introduced in [81] is an appropriate solution since these metrics are very intuitive and their measurement can be automated.

3.4. Reuse process A complete reuse approach should provide support for four steps: representation, retrieval, adaptation, and incorporation [95]. In the proposed approach, the representation step is supported by the first phase in which the model repository and the ontology repository are prepared. Further, retrieval and adaptation steps are addressed in the second step of the proposed approach. In this step, a use case diagram is taken as input, and for each use case in this diagram, the most similar use cases are retrieved from the model repository. Activity diagrams associated with these use cases are considered as candidate patterns for creating the corresponding activity diagram of the input use case. After the user has made his decision about which candidate is more appropriate, the selected activity diagram is adapted to create the output activity diagram. Two main components are involved in the process described above: a use case similarity metric and an algorithm for activity diagram adaptation. These components are described in the next sections.

3.4.1. Use case similarity metric A very basic idea for comparing two use cases is to see each use case as a bag of words, including names of the use case, associated actors and related use cases, and to measure similarity of two use cases by employing textual similarity metrics. This approach is followed in some works like [86], however, problems of relying only on textual similarity are well highlighted in the literature, for instance it is possible that two semantically similar use cases are named by different words, e.g. ‘Buy Book’ and ‘purchase product’, and therefore their textual similarity is low. 3

http://swoogle.umbc.edu/. http://watson.kmi.open.ac.uk. 5 http://ws.nju.edu.cn/falcons/. 6 http://sindice.com/. 7 CyCorp. ResearchCyc. http://research.cyc.com. 8 http://dbpedia.org. 9 http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/ LinkingOpenData. 4

The similarity metric proposed in the current paper address such issues by considering semantic similarity instead of simple textual similarity. Actually, it measures similarity of two use cases based on two aspects, i.e. similarity of the sole use cases, and similarity of the contexts in which the use cases exist. This metric is defined as below:

simðUC i ; UC j Þ ¼ W sem  semSimUC ðUC i ; UC j Þ þ W ctx  ctxSimðUC i ; UC j Þ where semSimUC(UCi, UCj) and ctxSim(UCi, UCj) are correspondingly the semantic similarity and the context similarity of the use cases UCi and UCj, and Wsem and Wctx are the weights that determine contribution of these two similarities to the overall similarity of UCi and UCj. 3.4.1.1. Semantic similarity. Semantic similarity of two use cases UCi and UCj is computed as a weighted sum of the similarity of the names of their behaviors, concepts, subjects and actors. These features are all textual information but the proposed metric measures their semantic similarity instead of pure textual similarity. This is based on WordNet [96] which represents relationships of different words in a network of words. WordNet is used in many works for the task of word sense disambiguation, semantic annotation or semantic similarity computation [97,87]. There are different algorithms, like Lin [98] or Wu–Palmer [99], for measuring semantic similarity of two words based on such a network. In the proposed metric, semantic similarity of use cases is computed by the following formula:

semSimUC ðUC i ; UC j Þ ¼ W S  semSimðSi ; Sj Þ þ W B  semSimðBi ; Bj Þ þ W C  semSimðC i ; C j Þ þ W A  semSimðAi ; Aj Þ where WS, WB, WC and WA are the weights which determine importance of the similarity of the subjects, behaviors, concepts and actors of the two use cases. Having two lists of terms T = {t1, t2, . . ., tm} and T0 = {t0 1, t0 2, . . ., t0 n} so that |T| 6 |T0 |, semSim(T, T0 ) is equal to the value of the best correspondence between T and T0 . Each correspondence is a set of assignments of t0 j (1 6 j 6 n) elements to ti (1 6 i 6 m) elements where no t0 j is assigned to more than one ti. The best correspondence is the one which has the largest value among all possible correspondences. Finally, value of a correspondence R is equal to:

P 2

0 ðt i ;t0j Þ2R WordNetSimilarityðt i ; t j Þ

jTj þ jT 0 j

where WordNetSimilarity(ti, t0 j) is computed by first stemming ti and t0 j, and then computing the semantic similarity of their stems by a WordNet based algorithm. 3.4.1.2. Context similarity. Context similarity of the use cases UCi and UCj is measured based on similarity of the corresponding use case diagrams UCDi and UCDj, using the following formula:

P ctxSimðUC i ; UC j Þ ¼

UC p 2UCDi MAX UC q 2UCDj

n

o

semSimðBp ;Bq ÞþsemSimðC p ;C q Þ 2

jUCDi j

where |UCDi| is the number of use cases in the use case diagram UCDi. The proposed metric allows assigning different weights to similarity of different features of the use cases. As described before, this metric is used to retrieve the use cases which their activity diagrams are candidates for adaptation. The idea is that generally, two activity diagrams with similar behaviors, even with different concepts, have greater similarity compared to two activity diagrams with different behaviors and similar concepts. Therefore, it

552

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

is reasonable to assign a greater value to WB, compared to WC. However, the exact values of the weight parameters should be set experimentally. 3.4.2. Activity diagram adaptation The input of the adaptation algorithm is (1) a use case UCnew of a new web application WAnew, (2) the associated use case diagram, and (3) a use case UCold of an existing web application WAold from the model repository. The output of the algorithm is an activity diagram ADnew which is adapted for UCnew from the activity diagram ADold associated with UCold. The algorithm is based on the idea that if UCold and UCnew have similar behaviors, it is possible to create ADnew through adaptation of ADold, even if the concept set of UCold and UCnew are different. If it is known that which elements of ADold are dependent on the concept set of UCold, then it is possible to create ADnew from ADold by replacing these elements with equivalent elements based on the concept set of UCnew. This is what is called activity diagram adaptation in the current paper. The adaptation algorithm works based on the annotations created by the annotation algorithm. If no annotation is generated for an activity diagram AD, then AD cannot be adapted. The better activity diagram AD is annotated, the more potential exists for AD to be adapted for new use cases. The proposed adaptation algorithm is presented as pseudo code in Fig. 4. It starts by retrieving ADold from the model repository, and creating a copy of it as the initial version of ADnew (lines 1–2). Then it retrieves labelsold, i.e. list of the labels of ADold (line 3). Then, for each label Lold from labelsold, its annotations are processed to create a label Lnew equivalent to label Lold. If a label is successfully created from an annotation, other annotations of that label are ignored. Finally if any equivalent label is created for Lold, it replaces Lold in ADnew (lines 5–16). The main issue in the adaptation algorithm is how to create the equivalent label Lnew based on the annotations of Lold. Considering different types of annotations described in the previous section, currently, the proposed adaptation algorithm only supports connected annotations and it ignores disconnected annotations. While this can be considered as weakness of the proposed algorithm, however we believe that if a web application is modeled precisely, most of its annotations must be connected. This is confirmed by the experiments discussed in Section 4.4.

As mentioned previously, a connected annotation ANNOTold of label Lold can be considered as a path of the form [ADold ? Lold ? ... ? UCold]. The idea is to generate Lnew by traversing this path in the reverse direction and synthesizing a path from UCnew to ADnew. Based on the type of ANNOTold, this is performed by slightly different procedures described below. Annotation Type 1: This annotation is a path of the form [ADold ? Lold ? CLold ? Cold ? UCold]. The synthesized path must be of the form [UCnew ? Cnew ? CLnew ? Lnew ? ADnew], and it is created from left to right. First Cnew must be created. Each concept in the concept set of UCnew is considered as a valid value for Cnew, because Cold has been a concept from the concept set of UCold. Next, CLnew is considered to be a class with the same name as Cnew, because CLold has been a class with the same name as Cold. Finally, since Lold has included name of CLold, Lnew is created by replacing name of CLold with name of CLnew in Lold. Finally Lnew is used as equivalent of Lold in ADold. Annotation Type 2: This annotation is a path of the form [ADold ? Lold ? Aold ? CLold ? Cold ? UCold]. The synthesized path must be of the form [UCnew ? Cnew ? CLnew ? Anew ? Lnew ? ADnew]. First Cnew is considered to be any concept in the concept set of UCnew. Then, CLnew is considered to be a class which its name is equal to Cnew, and Anew is considered to be any appropriate attribute of this class, because Aold has been an attribute of class CLold. Finally, since Lold has included name of Aold, Lnew is created by replacing name of Aold with name of Anew in Lold. Annotation Type 3: This annotation is considered to be a path of the form [ADold ? Lold ? CLold ? CL0 old ? Cold ? UCold]. The synthesized path must be of the form [UCnew ? Cnew ? CL0 new ? CLnew ? Lnew ? ADnew]. First Cnew is considered to be any concept in the concept set of UCnew. Then, CL0 new is considered to be a class which its name is equal to Cnew. Since there has been a relationship between CLold and CL0 old, CLnew is any class that has a relationship of the same type with CL0 new. For instance, if there is an association between CL0 old and CLold, then there should be an association between CL0 new and CLnew. Finally, Lnew is created by replacing name of CLold with name of CLnew in Lold. Annotation Type 4: This annotation type creates a path of the form [ADold ? Lold ? Aold ? CLold ? CL0 old ? Cold ? UCold]. The synthesized path must be of the form [UCnew ? Cnew ? CL0 new ? CLnew ? Anew ? Lnew ? ADnew]. First Cnew is considered to be any

Input: UCnew: a use case of a new web application WA new UCDnew: use case diagram of UCnew UCold: a use case of an existing web application WA old Output: ADnew: activity diagram of UCnew Algorithm 1. retrieve ADold from model repository 2. ADnew = copy of ADold 3. labelsold = list of the labels declared in ADold 4. foreach label Lold in labelsold { 5. Lnew = null 6. annotationsLold = list of annotations of Lold 7. foreach annotation annotLold in annotationsLold { 8. L = generate equivalent label of Lold based on annotLold 9. if L is not null { 10. Lnew = L; 11. break; 12. } 13. } 14. if Lnew is not null { 15. replace Lold in ADnew with Lnew 16. } 19.} 20. return ADnew Fig. 4. Pseudo code of the proposed adaptation algorithm.

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

553

SELECT ?CL ?attribute WHERE { ?CL rdf:type rdfs:Class . ?CL rdfs:label “Student” OPTIONAL { ?attribute rdfs:domain ?CL . } } Fig. 5. SPARQL query for finding classes named ‘Student’ along with their attributes.

concept in the concept set of UCnew. Then, CL0 new is considered to be a class which its name is equal to Cnew. Further, CLnew is any class which has a relationship to CL0 new of the same type as the relationship between CLold and CL0 old. Finally, Anew is any appropriate attribute of CLnew, and Lnew is created by replacing the name of Aold with the name Anew in Lold. Annotation Type 5: This annotation is a path of the form [ADold ? Lold ? ACold ? UCold]. The synthesized path must be of the form [UCnew ? ACnew ? Lnew ? ADnew]. First, ACnew is considered to be any actor which uses UCnew. Then, Lnew is created by replacing the name of ACold with the name of ACnew in Lold. An important issue is that since input of the proposed adaptation algorithm does not include class diagram of the new web application WAnew, some method is needed to find the required classes and attributes for adaptation of the annotations of type 2, 3 and 4. In order to find a class with a specific name, or a class which has a specific relationship with another class, first, the model repository is searched, because it is possible that the required class is declared in the class diagram of some existing web application. If this search has no result, then the ontology repository is searched for the concept with the same name as the required class. In order to find the required attributes of a class with a specific name, e.g. for adaptation of the annotations of type 2, first the corresponding class is found. Then, its attributes are retrieved and analyzed to select the most appropriate one. Different factors, like attribute names, attribute types and their multiplicity restrictions are considered for this purpose. For instance, by executing the query shown in Fig. 5 on the ontology repository, it is possible to search for classes named ‘Student’ along with their attributes. Further, to find a class that has a generalization relationship to another class named ‘Student’, the query shown in Fig. 6 can be used. As another example, an association relationship between two classes is considered to be reflected in the ontologies as an object property whose domain and range are the corresponding classes. For instance, to find a class which is associated with another class named ‘Student’, the SPARQL query of Fig. 7 can be used.

4. Evaluation In order to evaluate the proposed approach, several experiments are performed. In this section, first, the research questions which these experiments seek to answer are introduced. Then, the experimental setup and the evaluation results are described. 4.1. Research questions The proposed approach seeks to reuse existing models through a combination of annotation algorithm, a use case similarity metric, and an adaptation algorithm. Therefore, the main research question of the current work is: RQ1: Is it possible to effectively reuse existing models to automatically generate activity diagram for a new use case? In other words, does the proposed approach provide an acceptable amount of reuse?

In order to answer this question, each of the components of the proposed approach should be evaluated. As a result, finer grained questions which should be answered are: RQ2: Has the proposed annotation algorithm acceptable performance? RQ3: Is the proposed metric successful in measuring similarity of UML use cases? RQ4: Has the proposed adaptation algorithm acceptable precision? Further, the proposed approach uses an ontology repository for finding required domain information. This ontology is expected to be populated with ontologies collected from the semantic web. Therefore, it leads to two research questions: RQ5: Is the semantic web promising in terms of providing the required ontologies? More specifically, is it possible to effectively find required classes and attributes on the semantic web? RQ6: How does use of the ontology repository affect quality of the proposed adaptation algorithm? These research questions are investigated through experiments described in the following sections. Table 1 shows the sections in which each research question is addressed. 4.2. Experimental setup In order to execute the experiments, a prototype of the proposed approach is implemented in Java. The experiments are executed on a system with Intel Core2 Duo processor (2.26, 2.27 GHz), 4 GB RAM, and 64-bit Windows Vista operating system. To setup the model repository, a dataset of UML models of web applications is required. Unfortunately no such a standard dataset is publically available. Therefore, for the purpose of the experiments, a dataset is created which includes:  Models of 13 web applications downloaded from the website of UWE project.10  Models of the 10 Software Requirements Specifications (SRSs) provided for the authors by the Use Case Data Base (UCDB) team. Alchimowicz et al. [100] propose a use-case benchmark which specifies the typical attributes of use case based requirements specifications. Their work is based on precise analysis of a Use Case Data Base (UCDB) containing 16 industrial projects with a total of 524 use cases. While UCDB research team has not made these use cases publically available, but they have provided a set of 10 SRS in response to the request of the authors of the current paper.  Models of 10 projects which are developed by 4th year students of software engineering, during a course of Software Engineering II.  Models of 27 sample software systems which their descriptions are presented in different UML-related books like [68,76,69,70]. For each of these 60 software cases, the corresponding models are prepared by MagicDraw11 tool, and the associated XMI files are transformed to semantic representation by the model parser. The 10 11

http://uwe.pst.ifi.lmu.de/. http://www.nomagic.com/products/magicdraw.html.

554

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

6SELECT ?CL2 WHERE { ?CL1 rdf:type ?CL1 rdfs:label ?CL2 rdf:type ?CL2 rdfs:subClassOf }

rdfs:Class . “Student” . rdfs:Class . CL1 .

Fig. 6. SPARQL query for finding classes which generalize a class ‘Student’.

SELECT ?CL2 WHERE { ?CL1 rdf:type rdfs:Class . ?CL1 rdfs:label “Student” . ?CL2 rdf:type rdfs:Class . ?assoc rdf:type owl:ObjectProperty . ?assoc rdfs:domain ?CL1 . ?assoc rdfs:range ?CL2 . } Fig. 7. SPARQL query for finding classes associated with a class ‘Student’.

Table 1 Research questions addressed in the experimental evaluations. Research question

Corresponding section

RQ1 RQ2 RQ3 RQ4 RQ5 RQ6

4.8 4.4 4.6 4.7 4.9 4.10

resulting RDF triples are stored in the model repository which is implemented using OpenRDF API.12 4.2.1. Demographics Due to the lack of a standard benchmark for evaluating the proposed approach, the experiments are based on the results obtained from a group of experts. This group is composed of 7 Ph.D. students of software engineering with more than 4 years of experience in the software engineering domain. All the experts have passed three courses Software Engineering I, Software Engineering II, and Advanced Software Engineering during their bachelor or master degree. Further, three of the experts have also had the experience of teaching Software Engineering I and Software Engineering II in the recent 4 years. Finally, all the experts have experience in developing web based systems and also object-oriented software. For all the experiments described in the next sections, the experts have been provided with both printed version of the test models and also with the associated files which can be opened in MagicDraw tool. Further, no specific output format has been forced, and the experts have been allowed to provide their results in any format which is more convenient for them, e.g. drawing and writing the results on the printed papers, or typing the results in a file. 4.2.2. Preprocessing The models of the dataset are preprocessed based on the method described in Section 3.3.1. This has identified a number of misspelling errors (e.g. ‘adress’), and non-stemmed words (e.g. ‘unregister’). All the misspelling errors have been corrected, but other cases are not modified. The reasons are that (1) unlike misspelling errors, abbreviations are considered to be used intentionally by the creator of the model, and therefore it is not 12

http://www.aduna-software.com/.

appropriate to modify it and (2) it is interesting to see how the proposed approach performs in the presence of such issues. 4.3. Behavior/concept detection algorithm In this section, an experiment is discussed which evaluates the behavior/concept detection algorithm introduced in Section 3.2.1. First, a set of 475 use cases is selected from the repository, and the experts are asked to identify the behaviors of each use case by identifying the words in the name of the use case that specify the use case behavior. In case of concept detection, the experts are asked to manually determine in the use case name the words that specify concepts of that use case. The experts are asked to consider this point: ‘‘a term C in the name of use case UCi, is a concept of UCi, if it is an appropriate candidate for naming a class in the associated class diagram, or an attribute of a class, or an actor of the corresponding use case’’. The results created by the experts are regarded as the golden standard. It is worth noting that from the 475 use cases, 466 use cases were identified to have a behavior specified in their names. For the other 9 use cases, no behavior is explicitly specified in the name of the use case, for instance, the use case ‘Home’ or ‘general information’. The proposed behavior/concept detection algorithm is executed on the test dataset in terms of nine different methods. The first method, i.e. M1, uses an empty string as the salt. Methods M2–M9 all implement the proposed algorithms but as shown in Table 2, use different values for the salt. All the methods use the Stanford POS Tagger. Results of the experiment are presented in Table 2 (the cells which have the maximum value in each column are grayed). As it is shown in this table, in case of behavior detection, all of the methods have high precision, i.e. between 92% and 94%. However, the recall values range from 55% to 93%. Method M1 has very low recall and this acknowledges the necessity of using an appropriate salt. From the eight different values tested, some have resulted in poor recall (e.g. the salt value of M4 and M9), however there are also three cases, i.e. M2, M5 and M7, with high recall of 92% and 93%. In case of concept detection, all the methods have high recall, i.e. between 92% and 94%, but the precision values range from 69% to 87%. Method M1 has almost the lowest recall among the methods. This again highlights role of the salt in guiding the POS tagger. Further, the three methods M2, M5 and M7 which had the best performance in behavior detection have also provided the best

555

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570 Table 2 Evaluation of the behavior/concept detection algorithms.

Behavior Detection Algorithm Method

Precision (%)

Recall (%)

Recall (%)

F-Measure (%)

92

57

70

70

94

80

M1

F-Measure (%) Precision (%)

M2

“I want to “

94

93

93

87

93

90

M3

“I want to do “

93

65

77

74

94

83

M4

“Please “

92

55

69

70

94

80

M5

“I “

93

93

93

87

92

89

M6

“I do “

93

73

82

77

93

84

M7

“Do you “

94

92

93

86

93

89

M8

“Are you “

93

80

86

80

92

86

M9

“Let’s “

92

55

69

69

94

80

results in concept detection. This improves the reliability of the salt values associated with these three methods. This experiment demonstrates that if an appropriate salt is used, then the proposed behavior/concept detection algorithm has very good performance. Comparing results of the two algorithms, it is shown that the precision of behavior detection is better than that of concept detection (considering similar salt values). However, when the best candidate salt is used, both behavior and concept detection have a similar recall value of about 93%. In addition, it is shown that selecting an appropriate salt is feasible and more than one appropriate value exists. However, we do not provide a specific method for choosing the required salt. The point of view is that it is not costly, nor challenging, to find an appropriate salt by testing some suggestions. The values tested in this experiment are selected based on the intuition that usually name of a use case starts with a verb, and since this name is to be appended to the salt, the salt must be a string which can be meaningfully followed by a verb. Based on the results of this experiment the string ‘I want to’ is selected as the salt value in the next experiments. It is interesting to determine the reason why the concept detection algorithm has generated more false positives, and therefore its precision is reduced. By analyzing results of this algorithm it was identified that there are some general terms in the names of the use cases which are tagged as name by the POS tagger, but are not considered by the experts as the concepts of the use cases. For instance, for a use case named ‘Save customer information’, both words ‘customer’ and ‘information’ are tagged as name by the POS tagger, but none of the experts has selected the word ‘information’ as a use case concept. 4.4. Annotation algorithm In this section, an experiment is discussed which evaluates the proposed activity diagram annotation algorithm. A set of 20 Table 3 Some statistics about the annotation golden standard. Annotation Type 1 2 3 4 5 >5 Total

Concept Detection Algorithm

Salt

Count

Percent (%)

62 77 18 13 6 17

32 40 9 7 3 9

193

100

activity diagrams is selected from the model repository, and the corresponding model files are given to the experts in order to manually annotate each activity diagram. Specifically, the experts have been asked to annotate the labels of the activity diagram elements with appropriate entities from the corresponding model. The allowed entities are the classes in the class diagram, attributes of these classes, and actors in the corresponding use case diagram. The result of this manual annotation process is treated as the golden standard. Some information about this golden standard is given in Table 3. On average, each activity diagram has about 10 annotations. Further, about 91% of the annotations of the golden standard are connected annotations, i.e. of type 1–5, which their adaptation is already supported by the proposed adaptation algorithm. Further, 79% of these connected annotations (which are 72% of all the annotations) are of type 1 and 2. This means that successful adaptation of the annotations of type 1 and 2 has important effect on the overall quality of the adaptation algorithm. After preparing the golden standard, the implemented annotation algorithm is executed on the corresponding activity diagrams, and the results are compared with the golden standard. The evaluation results are presented in Fig. 8. The minimum precision, recall and F-measure of the proposed annotation algorithm are respectively 58%, 70% and 68%. Further, the average precision, recall and F-measure are correspondingly 90%, 88% and 89%, with standard deviation of 13%, 12% and 11%. This means that the proposed annotation algorithm has high accuracy and effectiveness, and a positive answer can be given to the research question RQ2. Further, the average time for annotating an activity diagram is 230 ms, which means the proposed annotation algorithm is efficient in terms of execution time. The last point is that as mentioned in Section 3.3.1, it is better that the number of annotations created for a label is limited to a small value. Regarding this issue, the annotation algorithm is promising since among the annotated labels, i.e. labels with at least one annotation, the average number of annotations per label is 1.1 annotations. As an example, the activity diagram named ‘CreateContact’ is shown in Fig. 9. The annotations identified by the experts are numbered in this figure, and details of the annotations found by the annotation algorithm are presented in Table 4. In case of this activity diagram, the annotation algorithm has successfully determined all the annotations. Although the experimental results demonstrate that the proposed annotation algorithm has very high precision and recall, however this algorithm has two potential weaknesses. First, it uses N-gram matching to compare labels of the activity diagram with the names of the classes, attributes, and actors. Therefore, it is

556

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

Fig. 8. Evaluation of the activity diagram annotation algorithm with annotation resolution enabled.

Fig. 9. Activity diagram ‘CreateContact’, along with its annotations.

557

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570 Table 4 Annotations of activity diagram ‘CreateContact’ (Fig. 9). Annotation number

Label

Annotation target

Annotation type

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

CreateContact CreateContactButtonPressed ContactDateInput Name email postalAddrMain postalAddrAlternative phoneMain phoneAlternative newContact reEditingContact saveNewContact newContact showAddressBook newContact saveContact searchForContactInAddressBook searchForContactInAddressBook

class Contact class Contact class Contact attribute name of class Contact attribute email of class Contact attribute postalAddrMain of class Contact attribute postalAddrAlternative of class Contact attribute phoneMain of class Contact attribute phoneAlternative of class Contact class Contact class Contact class Contact class Contact class AddressBook which has an association with class Contact class Contact class Contact class Contact class AddressBook which has an association with class Contact

1 1 1 2 2 2 2 2 2 1 1 1 1 3 1 1 1 3

sensitive to textual differences. For instance, if the label ‘postalAddrMain’ is replaced by a label ‘postalAddressMain’ in the activity diagram shown in Fig. 9, it would not be matched with the attribute ‘postalAddrMain’ of class ‘Contact’, although it might be considered as a valid match. The second weakness is that since the proposed annotation algorithm works based on a set of predefined rules, clearly, these rules do not cover all the possible cases. Consequently, the annotation algorithm might create incorrect annotations and these annotations might be not removed by the resolution algorithm. For instance, for the label ‘Comment Movie’ of the activity diagram ‘Comment Movie’ (Fig. 13), the annotation algorithm has created two annotations. The word ‘Movie’ is annotated with class ‘Movie’, and the word ‘Commnet’ is annotated with the attribute ‘comment’ from class ‘UserComment’ (the corresponding class diagram is shown in Fig. 14). While the first annotation is correct, the second one is not. Since here, the word ‘comment’ refers to the action of commenting, not to an attribute. In this case, no annotation must be created for the word ‘Comment’. In order to address the first weakness, instead of exact matching of the N-grams, a method of inexact matching should be employed which tolerates minor differences. Such a method can be designed based on existing algorithms of string edit distance computation. Additionally, for the first weakness to be reduced, it is required that the terms used in the activity diagram labels are consistent with the names of the classes, actors, and attributes. The more precise and complete are models of a web application, the more potential exists for annotating its activity diagrams, and the more promising the adaptation algorithm becomes. We have not yet performed experiments to evaluate how easy it is for the users to preserve consistency in their models. However, our point of view is that using consistent terms is not a strict limitation and it does not introduce new challenge for the user. In [64], the authors propose a set of 26 rules for restricting the way use cases are specified. Their goal is to provide more potential for automated model transformation and model processing techniques. The 9th rule is ‘‘Use words in a consistent way. Keep one term to describe one thing’’. This is what is expected by the annotation algorithm proposed in the current paper. Experimental evaluations discussed in [64] demonstrate that it is easy for the users to understand and follow the restriction rules. This supports our point of view that preserving consistency in the context of the proposed approach is also not challenging. In case of the second weakness, the rule set of the annotation algorithm must be carefully reviewed against a standard dataset of UML models, and if necessary, the rule set must be redesigned.

However, in the lack of a standard dataset of UML models, this becomes a challenge. The experiment discussed in this section is performed on models like UWE models which are provided by a research group focused on the web engineering domain. As a result, these models have good precision and consistency, and this has contributed to the considerable results of the experiment. Regarding the weaknesses described above, it is interesting to evaluate how the annotation algorithm performs on models created by less experienced users who probably do not create very precise and consistent models. As a result, the experiment is repeated on a dataset containing models that were previously created by 4th year students of software engineering as the final project of the ‘software engineering’ course. This dataset contains UML models of 23 different web applications like online forum, e-library and online shopping. Each project is associated with a group of 4–5 students, and therefore, it is very probable that some models are created collaboratively. For the sake of this experiment, the model validation step is ignored, to let the models be added to the model repository in their original form. Analysis of the results demonstrates that the average precision, recall and F-measure are respectively 84%, 72% and 76%. Further, minimum precision, recall and F-measure are respectively 44%, 38% and 42%. Analysis of the results demonstrates that inconsistent terms in the models are the main cause of the decrease in precision and recall. In many cases, the terms used in the activity diagrams have been inconsistent with the terms used in the class diagrams. For instance in one of the projects, a class ‘Student’ with two attributes ‘firstname’ and ‘lastname’ is defined in the class diagram, but in the activity diagram, the term ‘name’ is used to refer to the name of a student. Based on the experts’ judgment, the term ‘name’ should be annotated whether with the attribute ‘lastname’ of class ‘Student’, or with both attributes ‘firstname’ and ‘lastname’. However, in the lack of a ‘name’ attribute in class ‘Student’, the proposed annotation algorithm has annotated the term ‘name’ with an attribute ‘name’ from class ‘course’. Many of the false positives of the annotation algorithm have similar reasons. Further inspection revealed some reasons for the presence of inconsistencies in the models:  Since each project is developed by a team of students, it is possible that different parts of the models are created by different members without enough care and commitment to how the other members have defined their models.  Different parts of the models are defined with different levels of abstraction. For instance, some class diagrams are defined very detailed while the corresponding activity diagrams are very general and high-level.

558

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

Table 5 Evaluation of the role of annotation resolution algorithm.

Average precision (%) Average recall (%) Average F-measure (%) Min precision (%) Min recall (%) Min F-measure (%)

Annotation algorithm with annotation resolution

Annotation algorithm without annotation resolution

90 88 89 58 70 68

63 89 74 41 54 52

 The models have been created with the intuition that they are merely for documentation and they are not used in the implementation phase, and they do not contribute to the final executables. Therefore, the models are probably created without enough attention and effort. While this experiment shows that performance of the annotation algorithm degrades on poor quality models, it also should be noticed that the repository models are kind of reference models, and therefore they are expected to be precise models carefully selected. In that case, the performance of the annotation algorithm is acceptable.

the correct choice. In this example, both classes ‘LinkInfo’ and ‘User’ have an attribute ‘name’. However, name of the class ‘User’ is appeared in label L = ’userName’ just beside the name of attribute ‘name’, while name of the class ‘LinkInfo’ is appeared in the activity diagram name ‘Browse LinkInfos’. Since the physical distance of appearance of class ‘User’ to the word ‘name’ is less than class ‘LinkInfo’, class ‘User’ is selected as the correct indicator of the context of label L, and it is the owner of attribute ‘name’. In order to make role of the annotation resolution algorithm clear, the annotation algorithm is executed again on the 20 test activity diagrams of the experiment, but this time without using the annotation resolution. Table 5 provides some evaluation results about this experiment. Analysis of the results demonstrates that there are many incorrect annotations in the results. Consequently, the average precision and F-measure are correspondingly reduced from 90% to 63%, and from 89% to 74%, but recall is not changed. This means that none of the annotations that were removed by the annotation algorithm (when resolution was enabled) were correct annotations. In other words, the resolution algorithm does not have incorrectly removed any correct annotation. This analysis demonstrates that the resolution algorithm has an important effect on increasing precision of the proposed annotation algorithm while it does not have noticeable effect on reducing recall. As a result, the annotation algorithm is better to be used by the resolution algorithm enabled.

4.5. Annotation resolution algorithm 4.6. Use case similarity metric In this section, more details are provided about how the annotation resolution algorithm affects results of the proposed annotation algorithm. In the experiment discussed in the previous section, which involves annotation of 20 activity diagram, the annotation resolution algorithm is called 61 times (i.e. for 61 labels), which means an average of 3 calls for annotation of each activity diagram. Further, the resolution algorithm has resulted in elimination of a total of 89 annotations. As an example, considering the activity diagram ‘Add Image’ which contains two labels ‘name’ (Fig. 15), the annotation algorithm has initially created 5 annotations for each label ‘name’. Targets of these annotations are attribute ‘name’ from classes ‘Image’, ‘LinkCategory’, ‘LinkInfo’, ‘Keyword’ and ‘User’ (the corresponding class diagram is shown in Fig. 16). While these 5 classes all have an attribute named ‘name’, but the resolution algorithm has assigned a ‘medium’ priority level to the first candidate, i.e. attribute ‘name’ from class ‘Image’. The reason is that the concept ‘Image’ is mentioned in the name of the corresponding use case ‘Add Image’. Further, a ‘low’ priority level is assigned to other four annotations, and these four annotations are then removed, and only the first annotation is remained which is clearly the correct annotation. As another example, considering the activity diagram ‘Browse LinkInfos’ (Fig. 17), the annotation algorithm has initially created 7 annotations for the label ‘userName’. The word ‘user’ is annotated with class ‘User’ and also with actor ‘User’, and both annotations have received a ‘low’ priority level. However, based on the third filtering rule the second annotation is removed and the first one is remained which is the more appropriate annotation. Additionally, the word ‘name’ is annotated with attribute ‘name’ from classes ‘Image’, ‘LinkCategory’, ‘LinkInfo’, ‘Keyword’ and ‘User’. From these 5 annotations, the third one has a ‘medium’ priority level, because ‘LinkInfo’ is included in the concept set of the use case. The fifth annotation has a ‘high’ priority level because the label ‘userName’ includes name of class ‘User’ which attribute ‘name’ belongs to. The other three annotations have a ‘low’ priority level. The resolution algorithm has then removed the first four annotations and only the last annotation is remained, which is

In order to evaluate the proposed similarity metric, an experiment is conducted. In this experiment, 10 use case diagrams from different software cases are selected from the model repository, and for each use case diagram, one of its use cases is selected as the test use cases. Further, the human experts are asked to manually assess the models inside the repository, and suggest for each test use case the top-10 most similar use cases. The same set of use case diagrams are given to the implemented prototype and the resulting recommendations for each of the 10 use cases are obtained. Results associated with each use case are then compared with the suggestions of each expert. In the experiments discussed in this paper, WordNetSimilarity of two terms is computed based on Lin algorithm [98]. Actually, JAWS API13 is used since it provides implementation of a number of WordNet based similarity algorithms. This API is also used for the purpose of stemming. Further, the values of the weight parameters defined in the proposed metric are experimentally set as shown in Table 6. The proposed similarity metric is used to compute similarity of the test use case with all other use cases from the repository, and rank them by their similarity. The evaluation involves assessment of the output ranked list, using some well-known metrics from the Information Retrieval (IR) domain. The first metric is ‘‘Precision at k’’, or ‘‘P@k’’ that measures precision for the first k elements of the ranked list. For each test case, P@k is calculated for 10 different values of 1 6 k 6 10. In Fig. 10, the average P@k for all the 10 test cases is shown for two methods. The first method, i.e. Method1, uses the proposed metric with the weights shown in Table 6, and the second method, i.e. Method2, uses this metric with all weights set to 1.0. The second method is used to determine the importance of distinguishing between different features of the use cases. As shown in this figure, for Method1, the average precision at k = 5 and k = 10 levels is respectively 82% and 65%. This means that on average, there are four correct results among the first five recommendations of the algorithm, and also six or seven correct results among the first 13

Java API for WordNet Searching: http://lyle.smu.edu/~tspell/jaws/index.html.

559

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570 Table 6 Parameters of the proposed metric. Parameter Value

Wsem 0.8

Wctx 0.2

WS 0.1

WA 0.05

WB 1.0

WC 0.2

10 recommendations. This can be considered good precision. As a result, it is reasonable to configure the algorithm to return only the first 10 elements of the ranked list, in which case the user needs to evaluate a short list containing about seven good recommendations. For Method2, the average precision at k = 5 and k = 10 levels is respectively about 47% and 40%. These values are considerably smaller compared to the values associated with Method1. Mean Reciprocal Rank (MRR) is used as the second metric. It identifies the average rank in which the first correct recommendation of the algorithm appears. In case of Method1, for all the 10 test cases, the first correct result has appeared at rank 1, and therefore MRR = 1. For Method2 the value of MRR is computed as 3.7. The information of the 10 test cases, and the associated top-most use case recommended by Method1 is shown in Table 7.

As the third metric, 11-point Interpolated Average Precision (11pIAP) is used to measure precision at 11 different recall levels 0.0, 0.1, . . ., 1.0. First, for each test case, interpolated precision at level r, i.e. Pinterp(r), is calculated which determines the highest precision achieved for any recall level r0 P r. Then, 11-point Interpolated Average Precision is created by computing average value of Pinterp(r) over the 10 queries for the 11 different values of r. The result is shown in Fig. 11. As shown in this figure, it is possible to reach a precision of at most 70% at the recall level of 0.6. In other word, at the level in which 60% of the correct results are returned, at most 70% of the returned results are correct. Further, the most achievable precision at the recall level 1 is 53%, which means in order for the 100% of the correct results to be returned, it is necessary to accept a precision of at most 53% (i.e. only half of the returned results are correct). The experimental results discussed in this section provide a positive answer for the research question RQ3, and demonstrate that the proposed use case similarity metric is successful in effectively retrieving similar use cases for the purpose of reuse. Further, by comparing the results of Method1 and Method2, it becomes clear that the idea of distinguishing between different features of the use

Fig. 10. P@K of the use case recommendation algorithm.

Table 7 Sample results of the use case recommendation algorithm. Test use case

First recommended use case

Software case name

Use case name

Software case name

Use case name

AddressBook SecureAddressBook InternetMovieDatabase Social Network InternetMovieDatabase SimpleMusicPortal BibliometricInformationSystem MiniCustomerRelationshipManager

SecureAddressBook HospitalInformationSystem PublicationManagementSystem LibrarySystem SimpleMusicPortal PublicationManagementSystem HospitalInformationSystem InternetBasedSystemForJSARAadministration

DeleteContact DeleteUser ViewPublicationText Add item BuyAlbum ViewPublicationDetails ListPatientNames ModifyUserAccount

InternetMovieDatabase SecureAddressBook MobileNews SocialNetwork

DeleteContact DeleteUser View Movie Add Comment Buy Ticket ViewAlbumDetails List publications Modifying customer’s representative information (contacts) Comment Movie SearchUsers Read news Change Settings

SocialNetwork MiniCustomerRelationshipManager RNAComposer Library System

SimpleMusicPortal

DownloadAlbum

InternetBasedSystemForJSARAadministration

Add Image Looking clients table Reading references Change system settings DownloadFile

560

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

cases is sound and promising and further, that the weights mentioned in Table 6 provide good results. 4.7. Adaptation algorithm In order to evaluate the proposed adaptation algorithm, an experiment with 10 test cases is conducted. Each test case contains a use case UCnew and its corresponding use case diagram UCDnew from the new web application WAnew, and a use case UCold from the existing web application WAold. For each use case UCnew, UCold is selected by giving UCnew to the proposed recommendation algorithm, and choosing the first recommended use case. Further, for each use case, its concept set is determined by the proposed algorithm of Section 3.2.1. Then the corresponding concepts are given to two of the experts who have more than 3 years of experience in the field of semantic web and ontologies. The experts are asked to manually search each concept on the semantic web and find ontologies that define the corresponding concept. The experts are asked to not spend more than 60 min for finding ontologies associated with each concept. The resulting ontologies are used to build the ontology repository for using in the experiment.

After preparing the test cases and the ontology repository, for each test case, the adaptation algorithm is executed to create the draft of ADnew, i.e. activity diagram of UCnew, by adapting ADold, i.e. activity diagram associated with UCold. Then, for each test case, the corresponding UCnew, UCDnew, ADnew, and ADold are given to each expert to evaluate result of the adaptation algorithm on that test case. The purpose of this experiment is to evaluate how successful is the proposed algorithm in adaptation of the annotations created by the annotation algorithm. As a result, for each test case, the annotations of ADold are also given to the experts by marking the figure of the corresponding activity diagram (similar to what is shown in Fig. 9), and printing the details on a paper. For each test case, the expert is asked to verify whether each annotation of ADold is successfully adapted in ADnew. To do this, the expert is provided with the ontologies of the ontology repository which define the associated domain of UCDnew. Considering the schema defined by these ontologies, the expert is asked to decide whether the adaptation algorithm has created appropriate labels for each annotation. Finally, precision of the proposed adaption algorithm is computed as the ratio of the correctly adapted

Fig. 11. 11pIAP of the use case recommendation algorithm.

Table 8 Evaluation results of the adaptation algorithm. #

UCnew

WAnew

UCold

WAold

# of Annotations

1

Create Student

CreateContact

AddressBook

18

83

83

2 3 4 5 6 7

CreateContact DeleteContact DeletePublication BuyAlbum Buy Book Delete Teacher

CreatePatient DeletePublication DeleteContact Buy Ticket Buy Ticket RemoveFriend

HospInfo PVS AddressBook IMDB IMDB Philoponella

4 13 7 9 9 7

100 82 71 75 70 57

100 69 71 67 78 57

8 9

RemoveFriend Edit Course

University Information Systems AddressBook AddressBook PVS SimpleMusicPortal Online Book Store University Information Systems Philoponella University Information Systems Online Book Store

DeleteContact Edit customer’s profile FindPublications

AddressBook LibrarySystem

7 14

71 69

71 79

9

86

67

10

Search Book

Publication Management System

Adaptation Precision (%)

Adaptation Recall (%)

561

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

Fig. 12. Evaluation results of the adaptation algorithm.

Table 9 Adaptation results based on annotation type. Annotation type

Correctly adapted annotations (%)

Incorrectly adapted annotations (%)

Not adapted annotations (%)

1 2 3 4 5

91 85 22 24 0

7 13 73 41 33

2 2 5 35 67

annotations to the total number of adaptations made for ADnew. Recall is also calculated as the ratio of correct adaptations in ADnew to the number of annotations in ADold. Result of the experiment is presented in Table 8 and Fig. 12. The average precision, recall and F-measure are respectively 76%, 74% and 75% with standard deviation of 12%, 12% and 11%. The minimum precision and recall are both 57%. Additionally, Table 9 shows the results separated by the annotation type. As shown in this table, annotations of type 1 and 2 are adapted effectively. However, adapting annotations of type 3, 4 and 5 has been much less successful. As previously mentioned in Section 4.4, about 72% of all the annotations in the test dataset are of type 1 and 2,

which are successfully adapted by corresponding rates of 91% and 85%. Results of this experiment demonstrate that the proposed adaptation algorithm has acceptable accuracy and effectiveness, but more work is still required to improve its performance in case of annotations of type 3, 4 and 5. Considering the fact that the goal of the proposed approach is to automatically generate the draft of the required activity diagram, and not its final version, it can be stated that the proposed adaptation algorithm is promising, and hence, the answer of the research question RQ4 is positive. As an example, the result of the adaptation of the first test case is shown in Table 10. As shown in this table, the experts have considered 3 adaptations as being incorrect, and these adaptations are associated with annotations of type 2 and 3. It is interesting to note that for adaptations number 4–9, the adaptation is made by finding attributes of a concept named ‘Student’ in the ontology repository. Actually, the corresponding ontology is ‘Person Ontology’ [102] which has been found through Swoogle search, when building the ontology repository. This ontology is developed in the research projects of the European Commission’s Framework Programme [103]. In Section 4.4, an experiment is discussed which evaluates performance of the proposed annotation algorithm on a dataset of models created by students. It is worth noting that the adaption

Table 10 Adaptation results for the first test case. #

Original label

Adapted label

Annotation type

Correctness

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

CreateContact CreateContactButtonPressed ContactDateInput name email postalAddrMain postalAddrAlternative phoneMain phoneAlternative newContact reEditingContact saveNewContact newContact showAddressBook newContact saveContact searchForContactInAddressBook searchForContactInAddressBook

CreateStudent CreateStudentButtonPressed StudentDateInput Full Name email Zip code Street Address Telephone City newStudent reEditingStudent saveNewStudent newStudent ShowAlumni newStudent saveStudent SearchForStudentInAlumni SearchForStudentInAlumni

1 1 1 2 2 2 2 2 2 1 1 1 1 3 1 1 1 3

U U U U U U U U  U U U U  U U U 

562

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

algorithm is also evaluated on this dataset to see how its performance degrades on lower quality models. The average precision, recall and F-measure of the adaptation algorithm is correspondingly 66%, 45% and 53% which demonstrates that quality of the model repository has direct effect on the results of the proposed approach. This highlights the fact that the model repository should be built from good quality models. It is worth noting that for an activity diagram ADold, even if the adaptation algorithm has a precision and recall of 100%, it does not mean that the adapted activity diagram ADnew is 100% complete and it does not need any modification or improvement. It only means that all the annotations of ADold are correctly adapted and all the created adaptations are correct. However, it is possible that ADnew is far from the expected activity diagram because the annotation algorithm has not created the required annotations on ADold. Therefore, considering the results of this experiment in isolation cannot appropriately reflect the effectiveness of the whole proposed approach. As a result, another experiment is discussed in the next section which is aimed at evaluating the whole proposed reuse approach by measuring the reuse percent provided by this approach.

Table 11 Observable data used for measuring reuse. Poulin et al. [71]

Equivalent in the proposed approach

Shipped Source Instructions (SSI) Reused Source Instructions (RSI) Changed Source Instructions (CSI) Source Instructions Reused By Others (SIRBO) Software development cost Software development error rate Software error repair cost

Shipped Model Elements (SME) Reused Model Elements (RME) N/A N/A N/A N/A N/A

based on the ontology of the corresponding domain. The experts are asked to provide as output the set of edit operations they have performed ADnew. The allowed types of edit operations are: adding a new node, edge or label, removing an existing node, edge or label, and modifying an existing label. After collecting the results from the experts, reuse percent is computed separately for each diagram pair (ADnew, ADfinal) and for each expert. Reuse percent is computed using the following formula:

4.8. Reuse percent It is interesting to evaluate the proposed approach in terms of the amount of reuse it provides. In their outstanding work [71], Poulin et al. introduce a model for cost/benefit analysis of reuse programs in an organization. In this model which is based on collecting 7 types of observable data, 4 metrics are introduced, and using these metrics, a Return-On-Investment (ROI) model is defined. An important point about the metrics is that they are all defined at the source code level. In other words, the metrics use Source Line of Code (SLOC) as the sizing technique. The proposed approach in this paper is concerned with reuse of models, specifically UML activity diagrams, and therefore the metrics defined in [71] cannot be directly applied for evaluating this approach. One possibility is to use an estimation model for measuring size of an activity diagram in terms of SLOC. Robles et. al. have used such an approach in [50] for estimating size of UML class diagrams in terms of SLOC. Their estimation is based on the model proposed in [72]. Unfortunately, we have not found a similar estimation model for UML activity diagrams. Therefore, it was decided to adapt some of the metrics of [71] to the context of the proposed approach. As it is shown in Table 11, out of the seven types of observable data introduced in [71], only two types are currently applicable for evaluating the proposed approach. Since the proposed approach is not yet employed in a specific organization and there is not enough history for its usage, software development cost, software development error rate and software error repair cost is ignored. Further, since the current paper does not deal with role of the proposed approach during software evolution and subsequent releases, therefore CSI is also not considered. Finally, SIRBO is also ignored since it requires usage history of multiple organizations. In the lack of other observable data, it was decided to use reuse percent metric which is defined in [40] as:

Reuse percent ¼

RSI  100% RSI þ SSI

Reuse percent shows the amount of reuse provided through a process or in a product. An experiment is performed to evaluate reuse percent for the proposed approach. This experiment actually complements the experiment discussed in the previous section. The same results obtained from the adaptation algorithm in the previous experiment are again given to the experts. However, this time, the experts are asked to perform the required modifications on ADnew in order to create ADfinal as the final adaptation of ADold,

Reuse percent ¼

RME  100% RME þ SME

where Shipped Model Elements (SME) is the total number of elements, i.e. nodes, edges and labels, in the activity diagram ADfinal, and Reused Model Elements (RME) is the total number of elements in ADfinal which are the results of the proposed reused approach, i.e. the elements which have been in ADnew and are preserved during the modifications of the experts. This computation is based on assigning equal cost values to all the modification types. We admit that this is a simplistic view and more research is required to measure cost of each modification more realistically. This is, as will be described in Section 5, one of the directions in which the current work can be extended. Analysis of the results shows that the average value of reuse percent for the proposed reuse approach is about 76%. This means that on average, 76% of the elements of ADfinal are preserved from ADnew and 24% of the elements of ADfinal are resulted from manual modifications. Based on this result, the answer to the research question RQ1 is positive and the proposed approach is promising in terms of amount of reuse it provides.

4.9. Semantic web readiness The proposed approach expects that the ontology repository is initially or incrementally populated with the required ontologies. This is an offline and manual activity. However, it is interesting to assess the feasibility of dynamically finding required ontologies from the semantic web. An experiment is discussed in this section which evaluates how effectively it is possible to find the required ontologies automatically. This experiment seeks to find out for what percent of the classes declared in the model repository it is possible to find an ontological definition on the semantic web. However, since the semantic web contains various sources, it is not possible to search all of them. In this experiment, two sources are used as representatives of the semantic web: Swoogle: This search engine collects semantic web data from the web and provides facilities for searching over this data. In this experiment, to find a class named X and its attributes in Swoogle, it is programmatically searched for ontologies that define the term X. The resulting ontologies are then downloaded from the web and stored in a local repository. Then, a SPARQL query similar to the

563

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

one shown in Fig. 5 is executed on this repository to find classes named X along with their attributes. The query of Fig. 5 is the simple form of the query which is actually used in the experiments. There are some technical issues about this query and it can be modified to provide more results. For instance, in some ontologies, classes are defined by owl:Class predicate, instead of rdfs:Class. It is possible to augment the query with copies of the current clauses and replacing rdfs:Class with owl:Class in those new clauses. This increases size of the query, but also potentially increases its recall. LOD: It is possible to search the data of Linking Open Data (LOD)14 cloud by executing SPARQL queries on its endpoint. To find a class along with its attributes on LOD, the same SPARQL query that is used for Swoogle search is programmatically sent to LOD SPARQL endpoint. The response received back includes URIs of the corresponding classes and attributes. In this experiment a set of 50 classes are selected from the model repository. For each class, the two semantic web sources are searched to retrieve classes with the same name along with their attributes. The results are shown in Table 12. As it is shown in this table, for 72% of the test classes, at least one equivalent class, and for 50% of the test classes, at least one attribute is found on LOD. In case of Swoogle, these values are correspondingly 94% and 88%. For instance, for the test classes named ‘Date’ and ‘Artist’, some of the attributes found through Swoogle search is shown in Table 13. Result of this experiment demonstrates that the data space provided by the semantic web is promising for finding information about the required classes and attributes. Hence, it provides a positive answer for the research question RQ5 mentioned in Section 4.1. In this experiment, two specific semantic web sources are used, while there are other sources like Sindice15 that can be used in addition to these sources to improve the results. Further, we believe that it is possible to improve the search results by enhancing employed SPARQL queries to consider other possible ways of defining classes and attributes on the semantic web. It is interesting to evaluate execution time of searching the selected semantic web sources. Regarding Swoogle search, the execution time is affected by the following steps: 1. 2. 3. 4.

searching the corresponding class name in Swoogle, downloading resulting ontologies, storing the downloaded ontologies in the local repository, executing a SPARQL query on the local repository.

It is important to point that in the second step, list of the resulting ontologies is processed until whether 10 ontologies are successfully downloaded or all the entries are processed. To download each ontology, its cached version is downloaded from Swoogle. This has some benefits over downloading the ontology from its original source:  Since Swoogle caches only ontologies that are smaller than 5 MB, a guarantee is provided on the download time since large ontologies are not cached and hence they are ignored by the downloader module.  Since all the ontologies are downloaded from a single source, the download times are expected to be more uniform and more predictable.  Downloading the cached version eliminates the risk of referring to ontologies which their links are dead.

14 http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/ LinkingOpenData. 15 http://sindice.com.

Table 12 Experimental results of the first experiment.

Classes found (%) Classes found with at least one attribute (%) Classes found with at least one superclass (%) Classes found with at least one subclass (%)

LOD search

Swoogle search

72 50 70 67

94 88 84 76

Table 13 Some results from Swoogle search. Class name

Attributes

Date Artist

day, month, year, laterThan, date artist_description, birthday, collaborated_with, currentProject, gender, hasAddress, hasFax, nativeLanguag e, phone, weblog

Table 14 Execution time of the search procedures. Average execution time (ms) Swoogle search

LOD search

Step 1

Step 2

Step 3

Step 4

Total

Total

2145

14,387

534

118

15,184

13,160

Execution time of each step is measured for each of the 50 test classes, and the average value is computed. The results are presented in Table 14. As shown in this table, the average execution time for Swoogle search is about 15 s and it is mainly affected by the time of downloading ontologies. The average execution time in case of LOD search is about 13 s and it is a bit more efficient than Swoogle search. However, it must be noted that since results of both searches are added to the local repository for future reuse, Swoogle search has more contribution to enrichment of the repository, because it adds complete ontologies while LOD search adds only the retrieved triples. This experiment demonstrates that the proposed search methods are not appropriate for being interactively used by the user, since their execution time is not negligible. However, it is possible to employ these search methods for helping the repository manager in building the ontology repository. 4.10. Role of the ontology repository Since the proposed adaptation algorithm uses the ontology repository to acquire some of its required information, it is interesting to identify to what extent this repository affects quality of the adaptation algorithm. To do so, the experiment of Section 4.7 is performed again, but this time with an empty ontology repository. Analysis of the results demonstrates that the average precision is increased from 76% to 78%. The reason is that when the ontology repository is empty, a number of annotations are not adapted at all. Therefore, incorrect adaptations are reduced, and precision is increased. On the other hand, since these annotations are not adapted, number of the correct adaptations is also decreased. This has decreased the average recall from 74% to 59% (rate of decrease is 20%), and the average F-measure from 75% to 67% (rate of decrease is 11%). As a result, regarding the research question RQ6, it can be concluded that the ontology repository has considerable effect on improving quality of the proposed approach.

564

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

As an example of the role of the ontology repository, in case of the test case shown in Table 10, the annotations number 4–9 are not adapted when the ontology repository is disabled, while five annotations from these six annotations were successfully adapted in the previous experiment (Section 4.7). It is worth noting that the richer is the ontology repository, and the better is quality of the ontologies in the repository, the greater is potential of the proposed approach in providing reuse for applications of different domains. Further, this repository is supposed to be populated by the ontologies collected from the semantic web or built manually. While this reliance on the availability of the required ontologies is observed in similar works like [50,38,39,15,16], it might be considered as a limitation of the proposed approach. Regarding this issue, it must be noted that any approach which relies on the use of a repository, whether a repository of ontologies or a repository of design models, is subject to the issue that the required repository resources might be not available. While this issue cannot be guaranteed to be tackled completely, but as the experimental results in Section 4.9 show, the semantic web sources provide a rich enough data space for addressing this issue to much extent. Finally, our point of view is that if the proposed approach is to be deployed in an organization with focus on a specific application domain, then populating the ontology repository with the ontologies of that specific domain is not inherently different from or more challenging than building the model repository. 5. Discussions In this section, a discussion is provided on the threats to validity of the experiments described in Section 4. Then, some issues about the proposed adaptation algorithm are discussed. Finally, limitations of the proposed approach and the directions in which it can be extended are described. 5.1. Threats to validity The proposed approach is evaluated using different experiments discussed in Section 4. Here, different threats that might have affected these experiments are discussed. 5.1.1. Conclusion validity A threat affects conclusion validity of an experiment if it can lead the experimenter to make incorrect conclusions about a relationship in the observed data. Such a threat can be rooted in the lack of enough reliable observations or test data. In the experiments of the proposed approach, the volume of the dataset and the number of the experts are limited. This has been due to the lack of a large public UML dataset, and to the limited access to qualified participants who have expertise in software engineering and semantic web. As it can be concluded from the discussion provided in [82], comparable limitations exists in similar works that focus on UML artifact reuse [50], however, this may threat conclusion validity of the experiments. 5.1.2. Construct validity A threat to construct validity of an experiment can be caused by inaccurate measurement of what the experiment is supposed to measure. In the experiments discussed in Section 4, the measurements are mostly based on traditional information retrieval metrics like precision, recall and MRR. However, the golden standard which is used to make the comparisons is created manually by a limited number of experts, and therefore, it may pose threats to our measurements.

5.1.3. Internal validity Internal validity of an experiment is the extent to which the causal relationships concluded from the experiment are warranted. For instance, in the experiment discussed in Section 4.10 it is concluded that disabling the ontology repository slightly increases precision but noticeably reduces recall of the adaptation algorithm. If it is not warranted that the changes in precision and recall are actually due to disabling the ontology repository and they might be caused by some other factor, then internal validity of the experiment is threatened. Since the only difference between this experiment and the one discussed in Section 4.7 is that the ontology repository is disabled, then the change in precision and recall cannot be attributed to any other factor, and hence no threat is posed to internal validity. There are also other issues related to internal validity:  Selection of subjects: the experts who are participated in the experiments are all Ph.D. students who all have taken three courses Software Engineering I, Software Engineering II and Advanced Software Engineering. Based on the resume of the participants, there is no significant difference between their empirical experiences in software engineering and web application development. However, since three of the participants have also had teaching experience in software engineering, this may pose a threat on the internal validity.  Maturation: the participants have not been involved in any training course or workshop during the experiments. As a result, maturation effect is considered to be controlled to an acceptable level.  Subject motivation: the participants have been involved in the experiments on a voluntary basis and they have been well aware about the importance of the experiments. Therefore, they are considered to be well-motivated.  Learning effect: since the participants are not asked to repeat a test in any of the experiments, there is no room for ‘pre-test’ and ‘post-test’ issues, and as a result the learning effect is not a concern.  Persistence effect: the participants have not been previously involved in similar experiments, and as a result, persistence effect is considered to be negligible.  Fatigue effect: the time of each experiment is limited to two 100min sessions, with a 15-min rest between the sessions. Further, the experiments are conducted in separate consecutive days. Considering that the experiments discussed in Sections 4.3, 4.4 and 4.6 have not been demanding and the participants have not been asked to perform complex analysis, the fatigue effect is considered to be controlled to an acceptable extent, however in other experiments, like the ones discussed in Sections 4.7 and 4.8, fatigue effect might threaten internal validity. A possible way to limit this threat is to use a greater number of participants in the experiments, so that each participant is involved in a smaller task. 5.1.4. External validity External validity is the extent to which the conclusions of an experiment can be generalized to similar settings. Regarding the experiments discussed in this paper, the following issues are considered:  Materials and tasks used: in the lack of a large public standard dataset, we have collected a dataset from different sources as described in Section 4.2. While the size and the content of this dataset is comparable to the datasets used in similar studies, e.g. [50], the limitation of this dataset in terms of the number of models and the variety of the application domains is a threat

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

to external validity of our experiments. To address this issue, a larger dataset which covers a greater range of application domains should be employed. Meanwhile, it is worth noting that the test cases used in the experiments are selected randomly from the dataset to improve generalizability of the results.  Subjects: the participants in the experiments are Ph.D. students of computer engineering with appropriate experience in software engineering and web application development. Consequently, they can be considered as qualified enough to produce results for evaluating the proposed approach. 5.2. Adapted activity diagrams The proposed adaptation algorithm generates an activity diagram ADnew for the input use case UCnew by adapting an activity diagram ADold which is associated with an existing use case UCold. It is worth noting that in order for ADnew to be a good representative of UCnew, the following conditions should be held: 1. There is at least one use case UCold in the model repository which is similar enough to UCnew. By similar enough it is meant a use case which at least its behavior is similar to that of UCnew. 2. The proposed similarity metric is able to effectively measure similarity of two use cases, so that it can retrieve similar use cases from the model repository with appropriate precision and recall. 3. The activity diagram ADold provides an appropriate description for UCold. Since ADold is being used as a pattern for creating ADnew, if ADold is not a good representative for UCold, then it is not expected that it can lead to an acceptable ADnew. The more precisely ADold represents UCold, the greater is the potential that the adaptation of ADold provides a good representative for UCnew. 4. The activity diagram ADold has been precisely annotated by the proposed annotation algorithm, since the annotations of ADold determine the points in which the adaptations can be made. 5. The proposed adaptation algorithm is able to effectively utilize annotations of ADold for performing required modifications. The conditions number 1 and 3 are assumed to be held, since otherwise it is not reasonable to expect the proposed adaptation algorithm to produce good results. The other conditions are dependent on the accuracy of the components of the proposed approach and they are separately evaluated through the experiments. The experimental results discussed in Sections 4.6 for instance demonstrate that the proposed similarity metric is successful in effectively retrieving similar use cases from the

565

model repository, and hence, the second condition is met. The conditions number 4 and 5 also can be considered to be held based on the results of the experiments discussed in Sections 4.4, 4.7 and 4.8. As a result, the activity diagram ADnew generated by the proposed approach is expected to be a good representative of the input use case, although it still may need some modifications. 5.3. Limitations and future works The experimental evaluations discussed in Section 4 demonstrate that the proposed approach is promising. However, it has some limitations, and it can be improved in different ways. Some of these limitations along with interesting directions for future works are discussed below. Since success of the proposed annotation algorithm is much dependent on quality of the models in the model, current paper proposes a validation method for checking quality of these models. However, this validation method is limited to simple textual and syntax checking, and it cannot reveal semantic inconsistencies. For instance, if the term ‘name’ is used in an activity diagram to refer to an attribute ‘last name’ of a specific class, this inconsistency is not detected by spell checking or stemming. It is both challenging and interesting to propose semantic aware methods for detecting such issues. Further, it is interesting to work on tools, e.g. in terms of add-ons for popular modeling tools, for supporting validation and correction of the models as they are being created in the first place Considering the fact that employing strict model validation rules reduces applicability of the proposed approach, it is needed to improve also the annotation algorithm. In other words, the annotation algorithm must have more tolerance regarding quality issues in the repository models. Currently, the annotation algorithm uses N-grams matching with simple additional heuristics which has limited quality. For instance, it can match ‘student id’ with ‘StudentID’ but it cannot match ‘student id’ with ‘StuID’. This limitation can be reduced by employing more advanced techniques which are capable of inexact or approximate matching. However, these techniques should be designed carefully so that the number of false positives is also controlled. Further, as mentioned in Section 4.4, another possible improvement is to extend the set of rules which are used by the annotation algorithm and the annotation resolution algorithm respectively for creating and filtering the annotations. The proposed adaptation algorithm currently is limited to supporting only connected annotations, and it ignores all the disconnected annotations. More work is needed to investigate whether disconnected annotations can also be adapted.

Fig. 13. Activity diagram ‘Comment Movie’ from ‘IMDB’ web application.

566

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

Fig. 14. Part of the class diagram of ‘IMDB’ web application.

Another limitation of the adaptation algorithm is that currently it does not support structural modifications. In other words, it is limited to label modification and cannot add or remove elements (e.g. nodes or edges). It is a main direction for our future works to add to the adaptation algorithm support for structural modifications. A basic idea is that this support can be based on a set of predefined patterns. For instance, in the activity diagram shown in Fig. 9 there are six output pins from the node named ‘ContactDataInput’. These six output pins refer to the six attributes of the class ‘Contact’. As a result, it can be considered that these six output pins (and the associated six arrows) are all parts of a pattern, i.e. sending values of all the attributes of a class from one node to another node. Considering this pattern, when this activity diagram is being adapted for a new use case named ‘CreatePatient’, it probably should create a new output pin for each attribute of the class ‘Patient’, and therefore the resulting activity diagram might have more or less than six output pins. Therefore, a possible approach is to identify the recurring patterns in the activity diagrams, and to define the required structural modifications for each pattern. The workflow patterns introduced in [104,105] provide a good starting point for this pattern analysis of UML activity diagrams. A very interesting future work direction is to equip the proposed adaptation algorithm with powerful integration and reasoning techniques so that it can create ADnew not only from a single ADold, but also from a set of pattern activity diagrams. This way the output activity diagram can benefit from the information of different models, for instance by borrowing some elements from each of the input activity diagrams. A limitation of the current work is the simple model used to measure reuse percent. It is interesting to adapt the model and metrics proposed by Poulin et. al. [71] for evaluating the proposed reuse approach. The equivalent of the observable data mentioned in [71] need to be clearly defined and the corresponding metrics should be adapted. In the current paper, Shipped Model Elements (SME) and Reused Model Elements (RME) are used as replacement of SSI and RSI. However, there are some questions which should be answered in order to compute SME and RME more precisely. Actually, in the definition of SME and RME no distinction is made between adding and removing different types of model elements. It needs more research to identify how cost of manipulating different types of elements should be modeled. For instance, is

the number of mouse clicks required to modify ADnew to ADfinal a good primitive for cost measurement? What is the cost of each type of modification on a UML model? What is the ratio of the costs of two operations: adding a new edge between two nodes of a diagram, and adding a new node to the diagram? By addressing these issues, it is possible to provide more reliable measurement for evaluating the proposed reuse approach. A limitation of the current work is that it does not propose a well-defined method for evaluating candidate ontologies for building the ontology repository. Actually, it is left to the corresponding

Fig. 15. Activity diagram ‘Add Image’ from ‘Philoponella’ web application.

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

567

Fig. 16. Class diagram of ‘Philoponella’ web application.

Fig. 17. Activity diagram ‘Browse LinkInfos’ from ‘Philoponella’ web application.

person to manually assess quality of the ontologies. Current work can be extended by introducing a supporting method for ontology evaluation for the purpose of building the ontology repository. Our point of view is that a method similar to [81] is a good choice.

Another direction for future works is to investigate which of the existing semantic web sources are more promising for answering information needs of the adaptation algorithm, and also to propose more effective techniques for searching these semantic web sources.

568

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

6. Conclusion In this paper, an approach is proposed to reuse models of existing web applications for specification of the functional requirements of a new web application. The goal of the proposed approach is to help designers in specification of the functional requirements. More specifically, it takes brief description of the requirements in terms of UML use case diagram, and semiautomatically generates the drafts of the detailed description of the requirements in terms of UML activity diagrams. The proposed approach is composed of five main components: (1) a model repository which contains models of existing web applications, (2) an ontology repository including ontologies of different domains, (3) an annotation algorithm for detecting points in the activity diagrams where modifications can be made for the purpose of adaptations, (4) a use case similarity metric for retrieving from the model repository the use cases which are similar to a new use case, and (5) an adaptation algorithm which utilizes the model repository and the ontology repository to adapt an annotated activity diagram for a new use cases. The proposed approach is evaluated using a prototype implementation and through different experiments. The results demonstrate that the proposed annotation algorithm has an average precision and recall of correspondingly 90% and 88% on good quality models. Further, its results depend on the quality of the models in the repository. Therefore, a validation method is required to detect problematic issues in the models which are being stored in the model repository. Current paper proposes a simple method for this purpose. The proposed use case similarity metric is demonstrated to be successful in effectively measuring similarity of UML use cases. It has had an average P@K of 82% at level k = 5 and 65% at level k = 10. It is shown that if this metric is used for retrieving similar use cases, then the first correct results appears on average at rank 1. In case of the proposed adaptation algorithm, the average precision and recall are respectively 76% and 74%. This shows that while the proposed adaptation algorithm is promising, there is still much potential for it to be improved. The proposed approach uses the semantic web data model as the underlying representation format, and this has provided some benefits, e.g. automatic inference support, which have resulted in reducing complexity of the implementation and improving its flexibility. The proposed approach is associated with the semantic web also in the sense that it uses the semantic web sources for providing required information of the adaptation algorithm in terms of the ontology repository. The experimental results demonstrate that this idea is both feasible and promising, and that the ontology repository has non-negligible effect on the results of the adaptation algorithm. Finally, the average reuse percent of the whole reuse approach is about 76%. Consequently, it can be concluded that the proposed approach is promising and it successfully realizes the idea of providing a use case based reuse method for generating functional requirements models. Appendix A See Figs. 13–17. References [1] J.A. Aguilar, I. Garrigos, J.N. Mazon, J. Trujillo, An MDA approach for goaloriented requirement analysis in web engineering, Universal Comput. Sci. 16 (17) (2010) 2475–2494. [2] F.M. Ali, W. Du, Toward reuse of object-oriented software design models, Inf. Softw. Technol. 46 (15) (2004) 499–517.

[3] A. Alnusair, T. Zhao, Retrieving reusable software components using enhanced representation of domain knowledge, Recent trends in information reuse and integration, Lect. Notes Comput. Sci. (LNCS) (2012) 363–379. [4] A. Alnusair, T. Zhao, Component search and reuse: an ontology-based approach, in: IEEE International Conference on Information Reuse and Integration (IRI), 2010, pp. 258–261. [5] B. Anda, D.I.K. Sjoberg, Investigating the role of use cases in the construction of class diagrams, Empirical Softw. Eng. 10 (2005) 285–309. [6] C. Atkinson, T. Kuhne, Model-driven development: a metamodeling foundation, IEEE Softw. 20 (5) (2003) 36–41. [7] B. Bauer, S. Roser, Semantic-enabled software engineering and development, GI Jahrestagung 2 (2006) 293–296. [8] R. Bendraou, J.M. Jezequel, M.P. Gervais, X. Blanc, A comparison of six UMLbased languages for software process modeling, IEEE Trans. Softw. Eng. 36 (5) (2010) 662–675. [9] T. Berners-Lee, Linked Data. Design Issues for the World Wide Web. , 2006. [10] B. Bislimovska, A. Bozzon, M. Brambilla, P. Fraternali, Graph-based search over web application model repositories, in: 11th Int. Conf. on Web Engineering (ICWE), Paphos, Cyprus, 2011. [11] C. Bizer, J. Lehmann, G. Kobilarov, S. Auer, C. Becker, R. Cyganiak, S. Hellmann, DBpedia – a crystallization point for the web of data, J. Web Semantics 7 (3) (2009) 154–165. [12] A. Bozzon, M. Brambilla, P. Fraternali, Searching repositories of web application models, Lect. Notes Comput. Sci. 6189 (2010) 1–15. [13] G. Butler, L. Li, L.A. Tjandra, Reusable Object-oriented Design, Department of Computer Science, Concordia University, Montreal, 1999, pp. 19–21. [14] C. Calero, F. Ruiz, M. Piattini, Ontologies for Software Engineering and Software Technology, Springer, London, 2006. pp. 339–345. [15] V. Castaneda, L. Ballejos, M.L. Caliusco, Improving the Quality of Software Requirements Specifications with Semantic Web Technologies, Workshop em Engenharia de Requisitos, Buenos Aires, 2012. [16] V. Castaneda, L. Ballejos, M.L. Caliusco, M.R. Galli, The use of ontologies in requirements engineering, Global J. Res. Eng. 10 (6) (2010) 2–8. [17] S. Ceri, P. Fraternali, A. Bongio, Web modeling language (WebML): a modeling language for designing web sites, Comput. Netw. 33 (2000) 137–157. [18] O.D. Troyer, C. Leune, WSDM: a user-centered design method for web sites, in: 7th Int. World Wide Web Conf., Elsevier, 1998, pp. 85–94. [19] B. Dobing, J. Parsons, How UML is used, Commun. ACM 49 (2006) 109–113. [20] F.A. Durao, T.A. Vanderlei, E.S. Almeida, S.R.L. Meira, Applying a semantic layer in a source code search tool, in: The 2008 ACM Symposium on Applied Computing (SAC ‘08), New York, 2008, pp. 1151–1157. [21] M.J. Escalona, G. Aragon, NDT: a model driven approach for web requirements, IEEE Trans. Softw. Eng. 34 (3) (2008) 377–390. [22] M.J. Escalona, N. Koch, Metamodelling the requirements of web systems, Lect. Notes Bus. Inform. Process 1 (2007) 267–288. [23] W.B. Frakes, K. Kang, Software reuse research: status and future, IEEE Trans. Softw. Eng. 31 (7) (2005) 529–536. [24] R. Gronmo, B. Moller-Pedersen, From UML2 sequence diagrams to state machines by graph transformation, J. Object Technol. 10 (2011) 1–22. [25] H.J. Happel, S. Seedorf, Applications of ontologies in software engineering, in: Int. Workshop on Semantic Web Enabled Software Engineering, 2006, pp. 1–14. [26] O. Hartig, M. Kost, J.C. Freytag, Automatic component selection with semantic technologies, in: 4th Int. Workshop on Semantic Web Enabled Software Engineering (SWESE), Karlsruhe, 2008. [27] M.G. Ilieva, H. Boley, Representing textual requirements as graphical natural language for UML diagram generation, Softw. Eng. Knowl. Eng. (SEKE) (2008) 478–483. [28] A. Iqbal, O. Ureche, M. Hausenblas, G. Tummarello, LD2SD: linked data driven software development, in: 21th Int. Conf. on Software Engineering and Knowledge Engineering (SEKE), Boston, MA, 2009. [29] I. Jacobson, Use cases – yesterday, today, and tomorrow, Softw. Syst. Model. 3 (2004) 210–220. [30] I. Jacobson, Object-oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992. [31] S. Kang, H. Kim, J. Baik, H. Choi, C. Keum, Transformation rules for synthesis of UML activity diagram from scenario-based specification, in: 34th Annual IEEE Computer Software and Applications Conference, 2010, pp. 431–436. [32] I. Keivanloo, L. Roostapour, P. Schugerl, J. Rilling, Semantic web-based source code search, in: 6th Int. Workshop on Semantic Web Enabled Software Engineering (SWESE 2010), San Francisco, CA, 2010. [33] W. Kling, F. Jouault, D. Wagelaar, M. Brambilla, J. Cabot, MoScript: A DSL for querying and manipulating model repositories, Lect. Notes Comput. Sci. (2011) 180–200. [34] N. Koch, Software Engineering for Adaptive Hypermedia Applications, PhD Dissertation, Ludwig-Maximilians-University Munich, Munich, Germany, 2000. [35] N. Koch, A. Knapp, G. Zhang, H. Baumeister, UML-based web engineering: an approach based on standards, in: L. Olsina, O. Pastor, G. Rossi, D. Schwabe (Eds.), Web Engineering: Modelling and Implementing Web Applications, Springer, Berlin, 2008, pp. 157–191 (Chapter 7). [36] N. Koch, A. Knapp, S. Kozuruba, Assessment of effort reduction due to modelto-model transformations in the web domain, in: 7387, in Web Engineering, 2012, pp. 215–222.

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570 [37] N. Koch, S. Kozuruba, Requirements models as first class entities in modeldriven web engineering, in: 3rd Workshop on the Web and Requirements Engineering at ICWE 2012, 2012. [38] S.J. Korner, T. Gelhausen, Improving automatic model creation using ontologies, Softw. Eng. Knowl. Eng. (SEKE) (2008). [39] S.J. Korner, T. Brumm, Improving natural language specifications with ontologies, Softw. Eng. Knowl. Eng. (SEKE) (2009). [40] Y. Liang, From use cases to classes: a way of building object model with UML, Inf. Softw. Technol. 45 (2003) 83–93. [41] D. Lucredio, R.P.M. Fortes, J. Whittle, Moogle: a model search engine, in: 11th Int. Conf. on Model Driven Engineering Languages and Systems (MoDELS ‘08), Springer-Verlag, 2008, pp. 296–310. [42] S.J. Mellor, A.N. Clark, T. Futagami, Model-driven development, IEEE Softw. 20 (5) (2003) 14–18. [43] H. Mili, F. Mili, A. Mili, Reusing software: issues and research directions, IEEE Trans. Software Eng. 22 (6) (1995). [44] P. Mohagheghi, R. Conradi, Quality, productivity, and economics benefits of software reuse: a review of industrial studies, Empirical Softw. Eng. 12 (2007) 471–516. [45] S. Murugesan, Web application development: challenges and the role of web engineering, in: Gustavo Rossi, Oscar Pastor, Daniel Schwabe, Luis Olsina (Eds.), Web Engineering: Modelling and Implementing Web Applications, Springer-Verlag, 2008 (Chapter 2). [46] S. Murugesan, Web engineering: a new discipline for development of webbased systems, in: First ICSE Workshop on Web Engineering, Los Angeles, 1999, pp. 1–9. [47] E. Nowick, K.M. Eskridge, D.A. Travnicek, X. Chen, J. Li, A model search engine based on cluster analysis of search terms, Libr. Philos. Pract. 7 (2) (2005). [48] OMG, Model Driven Architecture, Object Management Group. , 2005. [49] S. Paydar, M. Kahani, A semantic web based approach for design pattern detection from source code, in: Int. Conf. on Computer and Knowledge Engineering (ICCKE 2012), Mashhad, Iran, 2012. [50] K. Robles, A. Fraga, J. Morato, J. Llorens, Towards an ontology-based retrieval of UML class diagrams, Inf. Softw. Technol. 54 (1) (2012) 72–86. [51] N. Samarasinghe, S.S. Some, Generating a domain model from a use case model, ISCA (2005). [52] D. Schwabe, G. Rossi, From domain models to hypermedia applications: an object-oriented approach, in: Int. Workshop on Methodologies for Designing and Developing Hypermedia Applications, 1994. [53] B. Selic, The pragmatics of model-driven development, IEEE Softw. 20 (5) (2003) 19–25. [54] A. Sen, The role of opportunism in the software design reuse process, IEEE Trans. Softw. Eng. 23 (7) (1997) 418–436. [55] H.H. Shahri, J.A. Hendler, A.A. Porter, Software configuration management using ontologies, in: 3rd Int. Workshop on Semantic Web Enabled Software Engineering (SWESE 2007), Austria, 2007. [56] M. Smialek, A. Kalnins, E. Kalnina, A. Ambroziewicz, Comprehensive system for systematic case-driven software reuse, SOFSEM 2010 (2010) 697–708. [57] S.S. Some, An approach for the synthesize of state transition graphs from use cases, in: Int. Conf. on Software Engineering Research and Practice (SERP’03), 2003, pp. 456–462. [58] J. Tappolet, C. Kiefer, A. Bernstein, Semantic web enabled software analysis, J. Web Semantics 8 (2010) 225–240. [59] P. Valderas, V. Pelechano, A survey of requirements specification in modeldriven development of web applications, ACM Trans. Web (ACM) 5 (2) (2011) 1–51. [60] P. Vilain, D. Schwabe, C. Sieckenius, Use Cases and Scenarios in the Conceptual Design of Web Application, Technical Report MCC 12/00, Departamento de Informatica, PUC-Rio, Rio de Janeiro, Brazil, 2000. [61] H. Yao, L.H. Etzkorn, S. Virani, Automated classification and retrieval of reusable software component, J. Am. Soc. Inform. Sci. Technol. 59 (4) (2008) 613–627. [62] T. Yue, L.C. Briand, Y. Labiche, A systematic review of transformation approaches between user requirements and analysis models, Requirements Eng. 16 (2) (2011) 75–99. [63] T. Yue, L.C. Briand, Y. Labiche, Automatically Deriving a UML Analysis Model from a Use Case Model, Technical Report 2010-15, Simula Research Laboratory, 2010. [64] T. Yue, L.C. Briand, Y. Labiche, Facilitating the transition from use case models to analysis models: approach and experiments, Trans. Softw. Eng. Methodol. (TOSEM) 22 (1) (2013). [65] T. Yue, L.C. Briand, Y. Labiche, An automated approach to transform use cases into activity diagrams, Lect. Notes Comput. Sci. (2010) 337–353. [66] IEEE, Guide to Software Requirements Specifications. ANSI/IEEE Standard 830-1998, 1998. [67] OMG Unified Modeling Language (OMG UML) Superstructure, version 2.4., 2011. [68] J. Conallen, Building web applications with UML, Addison Wesley, 2002. [69] K. Hamilton, R. Miles, Learning UML 2.0., O’Reilly, 2006. [70] S.J. Mellor, M.J. Balcer, Executable UML: A Foundation for Model-driven Architecture, Addison Wesley, 2002. [71] J.S. Poulin, J.M. Caruso, D.R. Hancock, The business case for software case, IBM Syst. J. 32 (4) (1993) 567–594.

569

[72] Y. Chen, B.W. Boehm, R. Madachy, R. Valerdi, An empirical study of eServices product UML sizing metrics, in: Proceedings of the International Symposium on Empirical Software Engineering (ISESE), 2004, pp. 199–206. [73] W. Schwinger, N. Koch, Modeling web applications, in: G. Kappel, B. Proll, S. Reich, W. Retschitzegger (Eds.), Web Engineering, The Discipline of Systematic Development of Web Applications, John Wiley & Sons, 2006, pp. 39–65 (Chapter 3). [74] G.J. Houben, F. Frasincar, P. Barna, R. Vdovjak, Modeling user input and hypermedia dynamics in Hera, in: 4th Int. Conf. on Web Engineering (ICWE 2004), Springer LNCS 3140, Munich, 2004, pp. 60–73. [75] P. Fraternali, P. Paolini, A conceptual model and a tool environment for developing more scalable and dynamic web applications, in: Proceedings of the Conference on Extended Database Technology (EDBT’98), Valencia, Spain, 1998. [76] J. Conallen, Building Web Applications with UML, second ed., AddisonWesley, 2003. [77] N. Guarino, C. Welty, Identity, unity and individuality: towards a formal toolkit for ontological analysis, in: Proceedings of ECAI-2000: The European Conference on Artificial Intelligence, Berlin, 2000, pp. 219–223. [78] D. Sleeman, Q. Reul, CleanONTO: evaluating taxonomic relationships in ontologies, in: 4th Int. Workshop on Evaluation of Ontologies for the Web (EON 2006), 15th Int. World Wide Web Conf. (WWW 2006), Edinburgh, 2006. [79] E. Damiani, KIWI: a framework for enabling semantic knowledge management, in: Semantic Knowledge Management, An Ontology-based Framework, 2009, pp. 1–24 (Chapter 1). [80] S. Dasgupta, D. Dinakarpandian, Y. Lee, A panoramic approach to integrated evaluation of ontologies in the semantic web, in: 5th International EON Workshop on Evaluation of Ontologies and Ontology-based tools, (EON2007) held at the 6th International Semantic Web Conference (ISWC), Korea, 2007. [81] H. Alani, C. Brewster, Metrics for ranking ontologies, in: 4th Int. EON Workshop, 15th Int. World Wide Web Conf., Edinburgh, 2006. [82] H.O. Salami, M.A. Ahmed, UML artifacts reuse: state of the art, Int. J. Soft Comput. Softw. Eng. (JSCSE) 3 (3) (2013) 115–122. [83] W.N. Robinson, H.G. Woo, Finding reusable UML sequence diagrams automatically, IEEE Softw. 21 (5) (2004) 60–67. [84] W.J. Park, D.H. Bae, A two-stage framework for UML specification matching, J. Inform. Softw. Technol. 53 (2010) 230–244. [85] H.O. Salami, M.A. Ahmed, A framework for class diagram retrieval using genetic algorithm, in: 24th Int. Conf. on Software Engineering and Knowledge Engineering (SEKE 2012), 2012, pp. 737–740. [86] B. Bonilla-Morales, S. Crespo, C. Clunie, Reuse of use cases diagrams: an approach based on ontologies and semantic web technologies, Int. J. Comput. Sci. Issues 9 (2) (2012) 24–29. [87] P. Gomes, F.C. Pereira, P. Paiva, N. Seco, P. Carreiro, J.L. Ferreira, C. Bento, Case retrieval of software designs using WordNet, in: European Conference on Artificial Intelligence (ECAI 02), 2002, pp. 245–249. [88] P. Gomes, F.C. Pereira, P. Paiva, N. Seco, P. Carreiro, J.L. Ferreira, C. Bento, Using Wordnet for case-based retrieval of UML models, AI Commun. 17 (1) (2004) 13–23. [89] M.C. Bloc, J.L. Cybulski, Reusing UML specifications in a constrained application domain, in: Proceedings of the 5th Asia Pacific Software Engineering Conference (APSEC), 1998. [90] T.A. Alspaugh, A.I. Ant, T. Barnes, B.W. Mott, An integrated scenario management strategy, in: Proceedings of the 4th IEEE International Symposium on Requirements Engineering, 1999, pp. 142–149. [91] P. Gomes, P. Gandola, J. Cordeiro, Helping software engineers reusing UML class diagrams, in: Proceedings of the 7th International Conference on Casebased Reasoning: Case-based Reasoning Research and Development, 2007, pp. 449–462. [92] A. Udomchaiporn, N. Prompoon, P. Kanongchaiyos, Software requirements retrieval using use case terms and structure similarity computation, in: Proceedings of the 13th Asia Pacific Software Engineering Conference, APSEC, 2006, pp. 113–120. [93] M. Saeki, Reusing use case descriptions for requirements specification: towards use case patterns, in: Proceedings of the 6th Asia Pacific Software Engineering Conference (APSEC), 1999, pp. 309–316. [94] B. Srisura, J. Daengdej, Retrieving use case diagram with case-based reasoning approach, J. Theor. Appl. Inform. Technol. 19 (2) (2010) 68–78. [95] A. Prasad, E.K. Park, Reuse system: an artificial intelligence-based approach, J. Syst. Softw. 27 (1994) 207–221. [96] G. Miller, Wordnet: a lexical database for English, Commun. ACM 38 (1995) 39–41. [97] E. Bagheri, F. Ensan, D. Gasevic, Decision support for the software product line domain engineering lifecycle, Autom. Softw. Eng. 19 (3) (2012) 335–377. [98] D. Lin, An information-theoretic definition of similarity, in: 15th Int. Conf. on Machine Learning vol. 1 (1998) 296–304. [99] Z. Wu, M. Palmer, Verb semantics and lexical selection, in: Proceedings of the 32nd Annual Meeting of the Associations for Computational Linguistics, 1994, pp. 133–138. [100] B. Alchimowicz, J. Jurkiewicz, M. Ochodek, J. Nawrocki, Building benchmarks for use cases, Comput. Inform. 29 (1) (2010) 27–44. [101] M.F. Porter, An algorithm for suffix stripping, Program 14 (2) (1980) 130–137. [102] Person Ontology. (last accessed 12.03.14).

570

S. Paydar, M. Kahani / Information and Software Technology 57 (2015) 543–570

[103] FP Research Project Ontologies. (last accessed 12.03.14). [104] W.M.P. Van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barros, Workflow patterns, J. Distrib. Parallel Dat. 14 (1) (2003) 5–51.

[105] P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, N. Russell, Pattern-based analysis of UML activity diagrams, in: 24th Int. Conf. on Conceptual Modeling, 2005, pp. 24–28.