Dependence Analysis for Software Architectures

Introduction — Software architectures model systems at high levels of abstraction. They capture information about a system’s components and how those components are interconnected. Some software architectures also capture information about the possible states of components and about the component behaviors that involve component interaction; behaviors and data manipulations internal to a component are typically not considered at this level. Formal software architecture description languages allow one to reason about the correctness of software systems at a correspondingly high level of abstraction. Techniques have been developed for architecture analysis that can reveal such problems as potential deadlock and component mismatches [2, 9, 12, 17]. In general, there are many kinds of questions one might want to ask at an architectural level for purposes as varied as reuse, reverse engineering, fault localization, impact analysis, regression testing, and even workspace management. These kinds of questions are similar to those currently asked at the implementation level and answered through static dependence analysis techniques applied to program code. It seems reasonable, therefore, to apply similar techniques at the architectural level, either because the program code may not exist at the time the question is being asked or because answering the question at the architectural level is more tractable than at the implementation level. This research introduces chaining, a dependence analysis technique for software architectures. In chaining, links represent the direct dependence relationships that exist in an architectural specification that, when collected together, produce a chain of dependencies that can be followed during analysis. The traditional view of dependence analysis is based on control and data flow relationships associated with functions and variables [1, 5, 8, 15, 19, 20]. This research takes a broader view of dependence relationships that is more appropriate to the concerns of architectures and their attention to component interactions. In particular, both the structural and the behavioral relationships among components expressed in current-day formal architecture description languages, such as Rapide [11] and Wright [2] are considered.