Introduction
The software reflexion model technique has been used to support design conformance tasks and to assess system structure before implementing changes. The software systems involved in the research by Murphy and Notkin were fairly large—from several thousand to quarter million lines of code. They have also success-fully applied their technique to a larger system under real-world schedule pressures. To derive a software reflexion model and iteratively refine it, the user performs five steps. I’ll discuss the first two in this article, whereas the rest will occupy the following articles.
Define high-level model
The high-level model describes aspects of the system structure that aid in reasoning about the software engineering task at hand. This step may involve reviewing artifacts (source code, documents), inter-viewing experts, or looking at similar architectures— anything that may give information about the system. For example, if the desired activity is to assess how difficult it would be to modify a compiler to generate code for a new platform, the user may choose to reason about the compiler in terms of a dataflow architecture. While analyzing a compiler, for example, the High-Level Model window of the reflexion tool shows a model of the compiler in which a parser produces an abstract syntax tree (AST) that interacts with a symbol table and code generator to produce object code. This step typically takes 15 minutes to an hour.
Extract source model
The user applies a tool like a call graph extractor or a file dependency extractor to extract interaction information from the source code. This information forms the source model that will be compared with the high-level model. In the compiler example, the user may employ a source model that captures calls between C++ methods as an approximation of the dataflow relationships in the high-level model.
Reference
Reengineering with Reflexion Models: A Case Study by Gail C. Murphy and David Notkin.
Go To Page: 1
