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:
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.
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
Sample Code
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