Enhancing Architecture-Implementation Conformance with Change Management and Support for Behavioral Mapping

Software architecture plays an increasingly important role in complex software development. Its further application, however, is challenged by the fact that software architecture, over time, is often found not conformant to its implementation. This is usually caused by frequent development changes made to both artifacts. Against this background, how to automatically maintain architecture-implementation conformance becomes a significant research question. Without this issue resolved, architecture centrality can only exist in ideal situations where developers are highly disciplined or the system under development is relatively simple.;Architecture-implementation mapping is a process that specifically addresses the conformance issue mentioned above. Existing approaches can be roughly classified as one-way mapping and two-way mapping depending on which artifacts can be manually changed. None of them, however, provides a complete solution in the sense that mapping of changes is weakly supported and most approaches can support structural conformance only. In this research study, a new mapping approach called 1.x-way mapping is developed. Its name comes from the fact that it only allows manual changes to be initiated from the architecture ("1") and a separated portion of the code (".x"). 1.x-way mapping advances the area of architecture-implementation mapping with the capability of preventing mistaken changes of architecture-prescribed code by programmers, and supporting automatic mapping of structural and behavioral architecture changes to code.;1.x-way mapping consists of four core mechanisms: a deep separation mechanism, an architecture change model, architecture-based code regeneration, and architecture change notifications. In a nutshell, the architecture-prescribed code and user-defined code of each architecture component are separated into two independent elements. Architecture-prescribed code can only be updated through code regeneration, and programmers' manual changes are limited to user-defined code. All the architecture changes are explicitly recorded and classified in an architecture change model. They are automatically mapped to code through the regeneration of architecture-prescribed code and the delivery of change notifications to user-defined code if necessary. Behavioral architecture-implementation mapping is enabled during this process with system dynamics modeled in a form that can be automatically translated into architecture-prescribed code that cannot be contaminated when programmers work on user-defined code.;Empirical evaluation of the 1.x-way mapping approach consists of three case studies based on ArchStudio 4, an Eclipse-based architecture development environment where 1.x-way mapping is implemented and integrated. In the first case study, we refactored the code of ArchStudio with the deep separation mechanism. In the next two case studies, we re-did, or replayed, changes made to the architecture and code of ArchStudio in two research projects with the help of our new mapping approach. The first project built and integrated an architecture-centric traceability tool in ArchStudio, and the involved changes were structure-oriented only. The second project was the development of the 1.x-way mapping tool, where both structural and behavioral changes were made to the ArchStudio architecture and code. The purpose of the evaluation is to determine if the 1.x-way mapping approach is applicable to real software development and its features are effective.