Resolving uncertainties during trace analysis
Software engineering notes
Software models provide independent perspectives onto software systems. Ideally, all models should use the same model element to describe the same part of a system. Practically, models elements are not shared b ecause of syntactic and semantic differences among modeling notations. Trace dependencies explicitly maintain the commonalities among the distinct model elements. Generating and maintaining trace dependencies is difficult, costly, and highly error-prone. Automated trace analysis
... e analysis techniques are scarce. This paper extends an existing, testing-based technique for generating and maintaining trace dependencies. It is based on the commonality principle: if two model elements of different perspectives are the same then they must have the same source code. The existing approach associates test scenarios with model elements, tests them, and observes what lines of code are being executed. Model elements are considered the same/similar if their testing uses the same/overlapping lines of code. This paper extends the existing approach (and tool) by giving the user a richer, more powerful, yet precise language on how to relate model elements, test scenarios, and source code (the input). This allows some forms of uncertainties to exist in input data without sacrificing reliability. The extended approach also identifies "shared code." Shared code works against the commonality principle in that model elements do not relate if they overlap solely on their use of generic source code ( e.g., queue). As a prerequisite, our approach requires an executable and observable software system and test scenarios.