Coolquest, Inc.	Home	Products	Support	About	Contact
C++BOLD Reference Manual

2.6. Work Flow

The following diagram illustrates the typical CBOLD work flow.

This flow assumes that the overall architecture and goals of the system are already established. The flow allows the detailed design of the system to occur simultaneously with the capture of the design. Designing is assumed to be an iterative process, so "Identify" should sometimes be read "Re–Identify", "Derive" should sometimes be read "Re–Derive", etc.

The diagram distinguishes between subsystem types and subsystem instances. It is possible to have multiple instances of the same subsystem type. Consider this example of a design that acquires and processes signals from two channels, X and Y:

class CM_Root : public TModule {
  ...
                            // subsystem declarations
  CM_Power          Power;  // power conditioning
  CM_PCI              PCI;  // PCI interface
  CM_FrontEnd           X;  // analog/digital front end for X channel
  CM_FrontEnd           Y;  // analog/digital front end for Y channel
  CM_Processor   DSP[ 8 ];  // array of eight processing units
  ...
};

The design contains a single power subsystem instance and a single PCI interface subsystem interface. It has two front-end subsystem instances, one for each channel, and an array of eight processing subsystem instances.

Of course, the designer could have opted for a single front-end subsystem instance that contained two member modules, one for each channel. Likewise, the designer might have been better off with a single processing subsystem instance that contained an array of processing module instances, e.g., to encapsulate interprocessor connections.

For large designs, the concept of Subsystems and Interfaces is indispensable. TBundle's are optional, but they can greatly increase the order and readability of a design.

In general, design approaches valid for C++ are also valid for CBOLD. For example, see Stroustrup Part IV, "Design Using C++".