Main concepts

ARCS is using the concepts component oriented programming. The main idea is to develop components (pieces of reusable software), group them into component libraries and glue them at runtime using a specific engine. Since ARCS is also a framework, it means it introduces component and application models and gives tools to implement and use them.

A software component is a piece of software that can be composed with other software components in order to produce an application. Usually software components have the ability to describe themselves and to be modified (through their properties for instance) at runtime (this is also called reflection). In ARCS, since it is using Qt intensively, the component model is inspired by Qt's meta-object system as well as the signal/slot communication paradigm.

To make it simple, component's inputs are called slots and component's outputs are called signals. Two components then are able to communicate when any signal of the first one is connected to any slot of the second one. The communication model is synchronous. It means that once a signal is triggered, the associated slots process it immediately.

In ARCS, every component is able to describe itself, that is to say to export the list of signals and slots it manages. It goes further than Qt because it can accept Qt's objects as components (native components) and also exogenous components (that is to say components we will make behave as if they were ARCS ones). Such model is described in the ARCSAbstractComponent class (which is actually a component factory). It exposes for each component recognized by ARCS the following functions:

• Export of signals and slots lists;
• Connection/disconnection management;
• Initialization of a component using its slots;
• Instantiation/destruction of actual component it manages;
• Serialization/deserialization from strings and files;
• A property system.

An application, under ARCS, is divided into two parts:

• A contextual part, describing what is needed by the application;
• A configurational part, describing how the application is structured, more exactly how data will flow between components.

The contextual part will contain all that is required by the application. It includes:

• Component libraries that will be loaded at runtime;
• A component pool that describes the component that will be actually used by the application;
• A constant pool of pre-defined values and properties that will be used by the application and that may be overridden by the engine.

The configurational part describes how the application is structured and how component will be initialized and connected to each other. This is where the actual model application resides. To make it brief:

• An application is composed of a set of processes (actually threads);
• Each process is controlled by a statemachine and is composed of a set of operational configurations (bound to states of the statemachine. i.e. each configuration corresponds to a particular state of the statemachine. Therefore, in a given process there is actually only one active configuration at a given time) called sheets;
• A sheet contains:
  • Pre-connection invocations to configure components before any connection is performed;
  • Connections to set the operational configuration and describe how components are linked to each other through signal/slot connections in which data are transferred;
  • Post-connection invocations that set the application into motion and run the configuration;
  • Cleanup invocations to restore component states if needed.

The engine loads the application description, then the component libraries at runtime. It instanciates components and constants if needed. Then, for each process, it will setup the first sheets. The sequence to start a sheet is the following:

• preconnection invocations are performed;
• connections between components are established;
• postconnection invocations are performed.

The postconnection invocations performed on components may trigger signals that will trigger other component slots through connections. It may eventually trigger a signal that sends a token to the controller. It then triggers a change of state. In that case, the actual sheet must be replaced by another one. The sequence to stop a sheet is the following:

• connections are undone;
• cleanup invocations are performed;
• the next sheet is started.