This document aims to specify the architectural specifications of the reflection model system for the C++ static binding unit. We find that our unit will conform to the architectural model of a pipe-and-filter partnered with a repository architecture. The overall architecture consists of two modules: the Parser and the Semantic Analyzer; and two repositories: the Symbol Table and the Core Model reference. An input source program is piped through to the Parser. This filter will use the Symbol Table repository to parse the input as per the key terms. This output is piped through as input to the Semantic Analysis filter that, using the Core Model reference repository, creates the Reflection Model, its output. This output will describe the architecture of the source code program that was originally inputted.

To describe our Reflection Model System Unit in precise terms we have chosen Acme, it is a simple, generic software architecture description language (ADL). It has been used as a common interchange format for architecture design tools and as a foundation for developing new architectural design and analysis tools. These reasons have thus motivated us to use the ACME language, here, to describe our architecture.

The C++ static architectural components consist of two modules and their repositories that they make use of :

The Parser Module: reads the source program as input and produces the tokens that contain information about class inheritance relations, class modules, class member functions, class data members and functions. Here the Symbol Table’s role as a repository comes into play. The Symbol Table contains all the C++ static/dynamic constructs. Once the Parser starts breaking up the input string into substrings, it will look into the Symbol Table for construct references. It will then fetch a given construct and generate a token along with its relevant information, such as its relations. This information will be saved into an object in memory for the Semantic Analyzer to begin processing.

The Semantic Analyzer Module: the main issue of our future design and implementation lies on the Semantic Analyzer module. It accepts input from memory by way of function calls to an object in memory, which contains all the extracted tokens. Once a token is considered valid for analysis, it is then sent to the Core Model. This constructor call to the valid object type desired will then instantiate new objects. The Semantic Analyzer would then in turn, call its output function, perhaps "toString()", to generate the output as needed.

Here is the illustration of our architectural model using ACME language.

// All filters define at least two ports

As it stands our architectural model is based on a degenerate pipe-and-filter architecture, a batch sequential architecture, coupled with two independent repository architectures. Each component of the system utilizes one repository independently. This however, lends itself to a certain flexibility. The repository, used by the parser, can be modified without any modification to the parser component. Any two filters can find themselves at the ends of a pipe, provided they agree on the data structure that is being transmitted between them. As well, components can be added, removed or changed without affecting the pipes. Such a system would allow the designers to understand the overall I/O behavior of said system; a simple composition of behaviors of the individual filters performed sequentially. Furthermore, it supports reuse. The system is not language specific in terms of its input. So long as the appropriate symbol table is contained in the repository used by the parser. The input will be parsed and then piped onto the semantic analysis filter.

There are other points that show the flexibility of the system. New functions or classes may be added to the program to extend its usability by adding additional filters. Since we are dealing with a high level architectural design, we feel the need of leaving some flexibility to further refine at a later time.