Design-code traceability recovery: selecting the basic linkage properties

Abstract Traceability ensures that software artifacts of subsequent phases of the development cycle are consistent. Few works have so far addressed the problem of automatically recovering traceability links between object-oriented (OO) design and code entities. Such a recovery process is required whenever there is no explicit support of traceability from the development process. The recovered information can drive the evolution of the available design so that it corresponds to the code, thus providing a still useful and updated high-level view of the system. Automatic recovery of traceability links can be achieved by determining the similarity of paired elements from design and code. The choice of the properties involved in the similarity computation is crucial for the success of the recovery process. In fact, design and code objects are complex artifacts with several properties attached. The basic anchors of the recovered traceability links should be chosen as those properties (or property combinations) which are expected to be maintained during the transformation of design into code. This may depend on specific practices and / or the development environment, which should therefore be properly accounted for. In this paper different categories of basic properties of design and code entities will be analyzed with respect to the contribution they give to traceability recovery. Several industrial software components will be employed as a benchmark on which the performances of the alternatives are measured.

[1]  M. Bunge.  Treatise on basic philosophy , 1974 .

[2]  M. Stone,et al.  Cross‐Validatory Choice and Assessment of Statistical Predictions , 1976 .

[3]  Paolo Tonella,et al.  Nomen est omen: analyzing the language of function identifiers , 1999, Sixth Working Conference on Reverse Engineering (Cat. No.PR00303).

[4]  D. C. Luckham.  ANNA, a language for annotating Ada programs: reference manual , 1987 .

[5]  G. G. Stokes.  "J." , 1890, The New Yale Book of Quotations.

[6]  David Notkin,et al.  Software reflexion models: bridging the gap between source and high-level models , 1995, SIGSOFT FSE.

[7]  Richard O. Duda,et al.  Pattern classification and scene analysis , 1974, A Wiley-Interscience publication.

[8]  Mikael Lindvall,et al.  Practical implications of traceability , 1996 .

[9]  Ralph Johnson,et al.  design patterns elements of reusable object oriented software , 2019 .

[10]  NotkinDavid,et al.  Software reflexion models , 1995 .

[11]  Roy H. Campbell,et al.  Monitoring compliance of a software system with its high-level design models , 1996, Proceedings of IEEE 18th International Conference on Software Engineering.

[12]  Mary Shaw,et al.  Software architecture - perspectives on an emerging discipline , 1996 .

[13]  Giuliano Antoniol,et al.  Design‐code traceability for object‐oriented systems , 2000, Ann. Softw. Eng..

[14]  Steven P. Reiss,et al.  Constraining the Structure and Style of Object-Oriented Programs , 1993, PPCP.

[15]  Peter E. Hart,et al.  Pattern classification and scene analysis , 1974, A Wiley-Interscience publication.

[16]  William E. Lorensen,et al.  Object-Oriented Modeling and Design , 1991, TOOLS.

[17]  Chris F. Kemerer,et al.  A Metrics Suite for Object Oriented Design , 2015, IEEE Trans. Software Eng..

[18]  Giuliano Antoniol,et al.  Evolving object oriented design to improve code traceability , 1999, Proceedings Seventh International Workshop on Program Comprehension.

[19]  Robert W. Schwanke,et al.  An intelligent tool for re-engineering software modularity , 1991, [1991 Proceedings] 13th International Conference on Software Engineering.

[20]  Christopher W. Pidgeon,et al.  Software change through design maintenance , 1997, 1997 Proceedings International Conference on Software Maintenance.