Improving system dependability by enforcing architectural intent

Abstract

Developing dependable software systems requires enforcing conformance between architecture and implementation during software development and evolution. We address this problem with a multi-pronged approach: (a) automated refinement of a component-and-connector (C&C) architectural view into an initial implementation, (b) enforcement of architectural structure at the programming language level, (c) automated abstraction of a C&C view from an implementation, and (d) semi-automated incremental synchronization between the architectural and the implementation C&C views.We use an Architecture Description Language (ADL), Acme, to describe the architecture, and ArchJava, an implementation language which embeds a C&C architecture specification within Java implementation code. Although both Acme and ArchJava specify C&C views, a number of structural differences may arise. Our approach can detect structural differences which correspond directly to implementation-level violations of the well thoughtout architectural intent. Furthermore, supplementing the C&C view extracted from the implementation with architectural types and styles can uncover additional violations.

Assisting the synchronization of UCM-based architectural documentation with implementation

“…The correspondence between architectural design and system implementation has been an active topic of research, with approaches that often employ visualization, reverse engineering and consistency checking tools [3,4,5,7,8,18]. Some commercial tools (e.g., Lattix, SonarJ, Structure101) provide basic support for monitoring structural compliance.…”

“…When these mappings no longer hold, the developers have to identify the mismatches and manually restore consistency. Some semi-automated approaches have tackled this problem through reverse engineering or structural analyses [3,4,5,7,8,18]. These approaches have shown benefits when dealing with structural mismatches, but they fall short regarding code deviations from the behavioral patterns prescribed by the architecture.…”

Differencing and merging of architectural views

“…For instance, during analysis, a software architect may want to reconcile two C&C views representing two variants in a product line architecture [CCG+03]. Once the system is implemented, an architect may want to compare a high-level conceptual C&C view with a C&C view retrieved from the implementation (using a variety of architectural recovery techniques): the architect might be interested in implementation-level violations of the architectural styles or other intent [AAG05], or in a change impact analysis [KPS+99]. At runtime, the difference information could be used to perform architectural repair [DHT02].…”