7. Conclusions 6. Related Works 5. Dealing with Inconsistencies Table 4. Design-code Class Comparison: Re- Sults Using Identity Criterion under the Re- Vised Matching Process

the tool is not provided with a high-level model representing all the system directly in terms of classes and relations to be compared with the corresponding information in source code, rather, more high-level models or partial models, which represent pieces of a system are provided to check compliance with specific parts of an implementation. Moreover, Pattern-Lint does not handle approximate matches like our system does using edit distance and REs. Design documents are often inconsistent with source code implementation for several reasons, e.g., because maintaining consistency is a costly and tedious activity and reducing time to market is often vital to face competition. However, being able to trace design into code is fundamental in both development and maintenance phases of the software life cycle. Automatic tools to support design-code compliance check, showing potential discrepancies and lack of trace-ability between the two artifacts are thus useful both in development and maintenance. Reports about design-code compliance, and especially graphical layouts such as the pair-difference diagrams are very useful, both for code and design inspections and for assessing the truthfulness of a design document before using it for maintenance tasks. The lesson learned by experimenting a design-code compliance check approach on a real industrial case study is that tools cannot rely on a perfect adherence of design and implementation: our first experiment based on class exact matching gave rather poor results of design-code traceabil-ity, reporting a high number of deleted and added classes. Furthermore, industrial software, and especially that developed with OO technology, often is built using a component-based strategy or based on COTS and libraries. Hence, a design-code compliance check tool must take into account the " physiological " inconsistencies between design and code represented by reuse and COTS, signal-ing them to the user with different priorities. To properly handle such cases we introduced the concept of similarity between entities in design and in code, relaxing the exact name matching and introducing edit distance and REs to account for deleted or added classes. The reviewed design-code compliance check approach has been applied again to the same industrial system and it has allowed to improve the figures of traceability, above all for the added classes, which decreased from 142% of the total design classes to 54%. Deleted classes have slightly decreased while common classes have remained invaried. Future work will be devoted to further experimenting the proposed approach to a wider set of …