A systematic literature review of academic and research papers on the subject of traceability between software architecture artifacts and source code is presented in this paper. It is well written and covers state-of-the-art techniques, as well as the gaps that exist in tracing architecture to its eventual implementation and source code. It puts forth a strong argument for pursuing empirical evidence for software architecture traceability while supporting completeness, consistency checking, and querying mechanisms using standard and widely accepted tooling support.
Although nearly complete from a literature review perspective, some issues lack adequate focus. First, the authors have made an implicit assumption that the evolution of the software architecture and the code base over a period of time causes serious problems for the consistency of traceability links with regard to the artifacts. Some additional literature that clearly establishes the relationship between increased code complexity and the traceability links to the architecture could have been included.
Second, the authors have not summarized or surveyed any existing mechanism with which architecture can be traced back to the code base. Hence, the statement that “separate evolution of artifacts causes mistrust in existing traceability” seems to stem from the authors’ unqualified assumption that architecture and code are in fact disparate artifacts, making traceability obsolete. There are techniques available in several source code management/application life cycle management systems that are currently in widespread use to ensure traceability from architecture decisions, through corresponding design decisions and test cases, to class modules and subsequent code.
Third, the authors make an incorrect statement that architecture and implementation are difficult to link because “architecture is not explicitly represented in the source code.” There are tools for auto-code generation; while the quality and readability of the code generated can be an issue, code can be generated directly from architectural artifacts such as component diagrams, deployment diagrams, sequence diagrams, state charts, and class diagrams.
Finally, in section 3, the authors indicate that low-level decisions (such as data structures and conditional statements) typically do not lead to design/architectural changes. While apparently true, poor low-level design choices can significantly impact design and architecture.
In summary, while the paper is a good attempt at a systemic literature review, there are gaps with respect to some related topics. For example, the paper could have included studies related to software architecture without traceability to make more practical and realistic recommendations.