OBS Framework

Implementation - Design Patterns

Manager Design Pattern

Intent

Provide a solution to the problem of managing a functionality that requires the same actions to be repeatedly performed on a class of components providing different implementations of the functionality itself.

Based On

This pattern is essentially equivalent to the manager meta-pattern of the AOCS Framework (see also: A. Pasetti, Embedded Control Systems and Software Frameworks, Springer-Verlag, 2002). .

Motivation

This design pattern is best seen as a meta-pattern that captures the commonalities design patterns like the telecommand management design pattern, the manoeuvre management design pattern, and the telemetry management design pattern. These design patterns are similar in that they all address the problem of organizing the repetive execution of certain actions. In all cases, these actions are encapsulated by components that are characterized by a certain abstract interface and there is a need to decouple the management of the actions from their implementation.

The purpose of capturing the commonality of the solutions offered by the management design patterns mentioned above is that this makes it easier to apply the same type of solution to other problems.

Dictionary Entries

The following abstractions or domain-wide concepts are defined to support the implementation of this design pattern:

• Functionality Manager
• Functionality Implementer

Structure

The design pattern assumes that the actions to be repetitively performed are defined by an abstract interface FunctionalityImplementer. Components that implement this interface are the functionality implementers that encapsulate the execution of the actions. The introduction of FunctionalityImplementer makes it possible to define an application-independent component, the FunctionalityManager, that is responsible for managing the execution of the actions. The functionality manager component will normally hold a list components of type FunctionalityImplementer and will expose an activation operation. When it is activated, the functionality manager processes the list of functionality implementers and decide whether or not to execute the actions they encapsulate. The decision is taken exclusively in terms of the information that is accessible through the FunctionalityImplementer abstract interface. The logic for processing the functionality implementers is functionality- and domain-specific. The functionality manager is therefore reusable for all applications within a certain domain.

In the case of the manoeuvre management design pattern, for instance, the functionality manager is the ManoeuvreManager and the functionality interface is the Manoevre interface.

Participants

• FunctionalityManager:  The application-independent component that is in charge of managing the functionality implementers. The functionality implementers are seen and manipulated exclusively through the FunctionalityImplementer abstract interface.
• FunctionalityImplementer:  The abstract interface that characterize all functionality implementers.
• FunctImplementer:  A concrete functionality implementer.

Collaborations

A typical operational scenario for this design pattern is:

• During the initialization phase, the functionality manager is configured with a list of functionality implementers that are loaded as instances of abstract interface FunctionalityImplementer.
• During the operational phase, the functionality manager is activated whenever the actions encapsulated by the functionality implementers need to be executed.
• The functionality manager may be dynamically reconfigured with new functionality implementers or with the removal of currently loaded implementers.

Consequences

• It is possible to define an application-independent and reusable component that encapsulates the processing logic for the functionality implementers.
• It is necessary to construct a dedicated class for each type of action that must be controlled by the functionality manager.
• It must be possible to capture all the essential information about the actions to be controlled by the functionality manager in a single abstract interface (the FunctionalityImplementer). This will sometimes cause this abstract interface to be overcomplex.

Applicability

There is a need to control the repetitive execution of actions that are sufficiently similar to allow their characteristics to be captured by an abstract interface.

Implementation Issues

Implementations will often combine the manager pattern with the mode management pattern. This will be necessary when the list of functionality implementers must be changed on a periodic basis or in response to changes in operational conditions. The implementation section of the telemetry management design pattern gives a concrete example of how the two design patterns can be combined.

The logic implemented in the functionality manager can be very complex. The functionality manager can query the implementers for information about their internal state and can process this information in order to decide whih actions to perform upon the functionality implementers. The important point of the design pattern is that everything the functionality manager does must be done exclusively through the FunctionalityImplementer abstract interface.

OBS Framework Mapping

The implementation of this design pattern in the OBS Framework is supported by the following classes:

• FunctionalityManagercomponent --> CC_TelemetryManager, CC_TelecommandManager, CC_PunctualActionManager, CC_ManoeuvreManager
• FunctionalityImplementerabstract interface --> TelemetryPacket, Telecommand, PunctualAction, Manoeuvre

As already noted, this design pattern is a generalization of design patterns like the telecommand management design pattern, the manoeuvre management design pattern, and the telemetry management design pattern. Readers should refer to the descriptions of these design patterns for examples of how the manager design pattern can be implemented.

Remarks

None

Author

A. Pasetti (P&P Software)

Last Modified

2003-07-29