 |
Consider the case of the AOCS software
and in particular the problem of reporting data to telemetry.
The object-based solution to the problem of telemetry data collection could
be as follows. An object is defined – the telemetryManager
– that is responsible for collecting telemetry data from other AOCS objects.
Thus, object telemetryManager holds
references to all the objects whose state should be included in telemetry
and uses the methods such objects expose to collect information on their
internal state. It then packages this information and sends it to the telemetry
stream. The resulting architecture is shown in the figure:
|
|
The light arrows indicate a relationship of association and the thick arrows indicate data flows. Note in particular that the telemetry objects are of different types and therefore the telemetry manager needs to manage references to a variety of types. For the same reason, it is difficult to manage the collection of telemetry information from different telemetry objects in a uniform manner because different objects provided different amounts of telemetry data and the operations with which these data have to be retrieved may differ across different types of telemetry objects.
The object-based architecture to telemetry management is represented by the following UML diagram:
Consider now the truly object-oriented solution to the telemetry problem. The design begins by identifying the fundamental functionality required for telemetry data handling. This is the ability of an object to write its own state to a telemetry stream . This functionality is encapsulated in the following abstract class (represented in C++ style):
class Telemeterable
{
void
writeToTelemetry()=0;
}
The classes of objects whose state might have to be sent to telemetry
are made to inherit from class Telemeterable.
This means that they will have to provide an implementation for the writeToTelemetry
method. The telemetry manager simply keeps a list of references to objects
of type Telemeterable and must
periodically call method writeToTelemetry
on each object in the list. The resulting architecture is shown in the
figure:
 |
The arrows now indicate an inheritance relationship. Note that the telemetry objects will in general implement other abstract interfaces representing their other functionalities. From the point of view of the telemetry manager, however, they appear as objects of type Telemeterable regardless of which other interfaces they may be implementing. This simplifies their management and makes the telemetry manager reusable. Thus, the telemetry manager relies on the objects it manages being of dynamic type Telemeterable. However, other components in the AOCS software will treat the same objects as being of a different dynamic type.
The object-oriented architecture can also be represented by the following UML diagram:
The basic implementation of the telemetry manager is as follows:
Telemeterable* list[N];
. . .
for (all objects
in list) do
list[i]->writeToTelemetry();
Clearly, this implementation of the telemetry manager is completely independent of the telemetry layout and content. This independence is achieved by using the abstract interface Telemeterable to separate the management of telemetry data from the implementation of the telemetry collection functions.
Note also that in the object-based approach, the telemetry manager acquires the data from the objects and sends it to telemetry whereas, in the object-oriented approach, the telemetry manager asks objects to write themselves to telemetry. This delegation of responsibility contributes to simplifying object interactions.
Back to Framework Design Principles, Back to Aocs Framework Project Home