Architectural Overview

Even though I tried very hard to build these utilities using reusable modules, as we start looking at a larger architecture a few things may have to change. As any experienced designer knows, the shape of individual components can change as the overall system in which they are used changes. I'm sure that the lower-level classes will be okay, but the converter classes may need some adjustments. It is prudent to defer major architecture changes until after requirements have been finalized, so I'm not going to try to sketch out even a block diagram at this point. However, we can think about some general characteristics of the architecture.

To facilitate ease of use we can provide users with a single program to invoke. We can further simplify use by letting them specify the name of the input and a single identifier for the type of conversion to perform. This identifier would point to a set of data in a data store that would contain the file description document specification (or equivalent) and other relevant details. With EDI formats as the input, all that might be necessary is a generic identifier for the EDI syntax since EDI interchanges have a lot of identifying information in them.

The main program would retrieve the details from the data store about the first transformation step and execute the appropriate filter. Then, based on other details from the data store regarding succeeding transformation steps, it would invoke the appropriate filters and write the final output. Output location could be determined either by information retrieved from the data store or from a command line argument. Allowing a user-specified system-level command for either the initial or final step would provide a way to invoke file transmission utilities.

The overall architectural style remains pipe and filter, but the individual filters retain an object-oriented design. This means that the main program creates converter objects of the appropriate classes as it needs them.