The study in Chapter 5 has shown that cloning abounds in many real-world requirements specifica- tions, and has given indication for its negative impact on engineering efforts. This section outlines promising directions for future work in clone detection in requirements specifications and other natural language software artifacts.
Clone Classification For code clones, a classification into different clone types has been estab- lished (cf., Section 2.2.3). Recently, an analogous classification of clone types for model clones has been proposed [86]. Such classifications are useful to characterize detection algorithms and thus facilitate their comparison and their selection for specific tasks.
Analog to code clones, we can define a classification of clone types for clones in natural language documents:
type-1 clones are copies that only differ in whitespace. They are thus allowed to show different positions of line breaks or paragraph boundaries.
type-2 clones are copies that, apart from whitespace, can contain replacements of words inside a word category. For example, an adjective in one clone can be replaced by an other adjective in its sibling, or a noun through another noun.
type-3 clones are copies that, apart from whitespace and category-preserving word replacements, can exhibit further differences, such as removed or added words, or replacements of a word from one category through a word from another one.
11.4 Cloning in Natural Language Documents
type-4 clones are text fragments that, although different in their wording, convey similar meaning. Just as the classification of code clones, this classification can be expected to evolve, as experience with cloning in natural language documents increases. For example, in [141], Koschke introduces further clone categories to better reflect typical clone evolution patterns. Similarly, a better un- derstanding of the evolution of requirements specification could lead to a refinement to the above categorization.
Detection of Type-2 Clones The classification of clone types raises the question of how they can be detected. Type-1 clones are easy to detect, since no normalization beyond whitespace re- moval needs to be performed. Detection can then simply be performed on the word sequence, as suggested in Chapters 5 and 7. Type-3 clone detection can be applied to this word sequence as well, e. g., employing the algorithm proposed in Chapter 7 for detection of type-3 clones in sequences. For type-2 clone detection, however, a normalization component is required that transforms ele- ments that may be substitute one another into a canonic representation. Since the above definition only allows word replacements inside a word category, such as nouns, verbs or adjectives, we need a component that identifies word categories for natural language text.
Natural language processing [119] developed a technique calledpart-of-speech analysisthat deter-
mines the word categories for natural language text. Part-of-speech analysis is a mature research area, for which freely available tools, such as TreeTagger [206, 207] exist, that are also used for other analysis tasks, such as ambiguity detection [82].
To evaluate the suitability of part-of-speech analysis for normalization, we have prototypically im- plemented it into ConQAT and evaluated it on one of the specifications from the case study on cloning in requirements specifications from Chapter 5. Initial results are promising: we detected type-2 clones that differ in the action that gets performed in a use case, e. g.,createversusmodifyof
a program entity, or in the tense in which the verbs are written; several clone groups only differed in the name of the target entity on which use case steps were performed, although the steps were identical.
In the instances we saw, normalization increased robustness against modifications. For example, the term “user” had been replaced by the term “actor” in some, but not all of the use cases. Such systematic changes cause many differences in the word sequences and thus make them difficult to detect using edit-distance-based algorithms; normalization, however, compensates such modifica- tions, thus making their detection feasible.
Many open issues remain: how does part-of-speech normalization affect precision? Which normal- ization of word categories gives a good compromise between precision and recall? Should some word categories be ignored entirely, e. g., articles or prepositions? Can automated synonym detec- tion approaches serve to provide a more fine grained normalization than part-of-speech analysis? Natural language software artifacts often adhere to a template; does the resulting regular structure enable improvements or optimizations? Future work is required to shed light on these issues.
11 Future Work
Evolution of Requirements Clones Requirements specifications—like all software artifacts— evolve as the system they describe changes. Unawareness of cloning during document maintenance threatens consistency: just as for source code, unintentionally inconsistent changes can introduce errors into the documents.
Little is known about how requirements specifications evolve, and how evolution is affected by cloning. How large is the impact of cloning on requirements consistency and correctness in practice? Which classes of modifications are often encountered in real-world requirements evolution and should thus be compensated by clone detectors? Empirical studies could help to better understand these issues.
Cloning in Test Scripts In many domains, a substantial part of the end-to-end testing is still performed manually: test engineers interact with the system under test, trigger inputs and validate system reactions. The test activities they perform are typically specified as natural language test case scripts that adhere to a standardized structure that is defined by a test case template. As the system under test evolves, so do its test cases.
To get a first understanding whether test cases contain cloning, we performed a clone detection on 167 test cases for manual end-to-end tests of an industrial business information system. For a minimal clone length of 20 words, detection discovered about 1000 clones and computed a clone coverage of 54%.
Manual inspection of the test case clones revealed frequent duplication of sequences of interaction steps between the tester and the system. Some of the steps, specifying both the test input and the expected system reaction and state, occurred over 50 times in the test cases. The employed test management tool, however, did not facilitate structured reuse of test case steps, thus encouraging cloning. However, if the corresponding system entities change, test cases probably need to be adapted accordingly. These results thus suggest that cloning in test scripts creates similar problems for maintenance, as it does in source code, requirements specifications and data-flow models. Empirical research is required to better understand the extent and impact of cloning in test scripts in practice. Does it increase test case maintenance effort? Does unawareness during maintenance cause inconsistent or erroneous test scripts? Can clone detection support automation of end-to-end tests by identifying recurring test steps that can be reused across automated test cases?