Working session: identification of lower-level artifacts

When programmers approach the task of maintaining a software system to modify existing code to correct errors, to add new functionalities or to upgrade it, often their first activity is to build a mental model of the system being studied. In order to understand the organization of a system at different levels of abstractions, maintenance requires the identification of sub-systems, of their functionalities, of their interactions, and of their relation with the different software artifacts. Unfortunately, documentation is often scarce or not up-to-date. Furthermore, since outsourcing has been widely adopted as common practice, people who wrote or maintained a system may no longer be available. Hence, the only reliable source of information about a program is often the program itself.Different approaches and tools have been proposed to help people in building conceptual models of existing systems either at the architectural level or at the code level. The architectural level relies on tools and technologies to extract lower-level artifacts from code and abstract architectural properties from them. To be effective, a fundamental requirement of any approach based on source code analysis is its ability to successfully deal with the full spectrum of a programming language syntax and semantics. However, many widely used modern programming languages, as C/C++, Pascal, Ada, etc. contain features such as structures, pointers, function pointers, polymorphism, inheritance, subtyping, and so on, which, while they augment a language expressivity and offer greater implementation flexibility to software developers, they also make the process of recovering even elementary information such as the call graph or the dependency graph harder.Pointer analysis algorithms provide programmers with a representation of the references between memory locations. The result is a useful view in itself, but is also a preliminary requirement for subsequent computations. Once language features are dealt with, two main categories of approaches can be conceived depending on whether or not we explicitly know what we are seeking. The first category comprises library-based approaches such as clone detection, clich based approaches, plan recognition, design pattern recovery and more generally approaches exploiting a set of ?examples?. The second category exploits the idea of clustering entities with similar or desired properties into abstract data types, into objects and into more general new structures such as domain or application specific patterns. Concept analysis is probably the most widely known approach adopted for this category of problems.Still the entire ?weaponry? requires underling sophisticated technologies, highly trained people, and adequate hardware resources. It is not clear how the lab approaches may be effectively exported into the every-day industrial practice. That is: 1. Do we really need all this stuff?2. Do we know companies who are willing to apply or who are currently applying these approaches?3. What step forward is required to bring into effectiveness the lab technologies?4. What obstacles should be removed to bring into effectiveness the lab technologies?5. How can we avoid technology being used as a surrogate of management responsibilities? i.e., how to avoid the dictatorship of tools? how can we avoid that if a tool says something, then it must be so?6. How can technology transfer be accomplished?