As a software engineering undergrad who was part of the honors program at RIT, I was required to complete an independent study. At the time I was taking a course in concurrent systems and was making extensive use of the Labelled Transition System Analyzer (LTSA), a concurrent system modeling tool which uses Finite State Process (FSP) algebra notation to represent component behavior.
Once a system is specified in FSP notation, the LTSA can parse and compile the FSP notation to generate a graphical Labeled Transition System (LTS) model. The LTSA also provides a means to “animate” the system by performing discrete or shared process behaviors one at a time and stepping through the states of the system. Under the hood, the LTSA generates and stores an internal state machine representation of the system.
One of the major difficulties encountered by software engineers who use the LTSA is deciding how to translate the FSP system representation into an executable implementation. A common practice is to use the LTSA as a system design tool and to deviate from the FSP during the implementation phase in order to create a custom-tailored system from the ground up. The major disadvantage is that the implemented system may no longer exhibit the same behavior as the FSP and therefore will need to undergo an entirely separate, and more complex, verification process.
Clearly, it is advantageous if the system implementation reflects the original FSP design. At the time when I was conducting my independent study there was no widely accepted procedure for converting the FSP into source code. I began developing the an automatic code generation backend called the FSP Autocoder to use the LTSA to parse FSP notation and perform semantic analysis to produce code stubs for primitive concurrent objects.
Before I could begin working on the compiler aspect of the autocoder, I needed to design a “universal” (i.e. widely applicable) concurrent system architecture that could be traced back to the FSP system representation and vice-versa. I considered many approaches, such as employing a state machine architecture, rendezvousing threads in conjunction with a round-robin thread scheduler, and using a Communicating Sequential Processes (CSP) library.
Resources: