When programmers perform maintenance tasks, program understanding is often required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e., its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems by showing them architectural information.

This paper describes an environment for the architectural recovery of software systems called the architectural recovery tool (ART). The environment is based on a hierarchical architectural model that drives the application of a set of recognizers, each producing a different architectural view of a system or of some of its parts. Recognizers embody knowledge about architectural clichés and use flow analysis techniques to make their output more accurate.

To test the accuracy and effectiveness of the ART, a suite of public domain applications containing interesting architectural organizations was selected as a benchmark. Results are presented by showing ART performance in terms of precision and recall of the architectural concept retrieval process.

The results obtained show that cliché-based architectural recovery is feasible and the recovered information can be valuable support in reengineering and maintenance activities.

Yann-Gaël Guéhéneuc, 2013/09/06

In this paper, the authors introduce the problem of architecture recovery. They also recall the problem of identifying the connections among components. To recover components and their connections, they devise a hierarchical component model and adapt the taxonomy of inter-process connectors (IPC) first proposed by [[A Syntactic Theory of Software Architecture|Dean and Cordy] to describe the possible connections among components. The connections can be:

• Shared-file: a data repository shared by several components. This type of connections is nowadays probably realised through the use of a database.
• Shared-memory: a data repository in which data can be accessed randomly and that is shared by components. This type of connections recalls the “black board” architectural style. It assumes that the components have access to a shared memory and are, probably, on a same machine. Nowadays, such a use of shared memory probably translate into the use of a database or object story, such as Haystack.
• Remote procedure call: a procedure call-like mechanism between components. Nowadays, most components interact through RPC, in particular with the advent of service-oriented architectures. How components can know about one another and invoke their procedures are interesting questions.
• Stream: a unidirectional or bidirectional ordered exchange of data between components. This is implemented through “piping” between components. Nowadays, piping is heavily used in Unix-like systems but probably not so much in more “general” component-based systems.
• Message: a data exchange among an arbitrary number of components. This type of connections also recalls the “black board” architecture but it may be also about having a “software bus” shared by components.
• Invocation: a connector that represents one component starting another component. This type of connection is probably implemented using fork() (C/C++) or Runtime.exec() (Java) or similar mechanisms.