Communication boundarycontrol

An important issue that needs particular attention is the communication between boundary and control objects. As previously mentioned, the boundary class is platform dependent and the control class is platform independent. The communication between these two objects should be modeled in such a way that the resulting system is flexible. Changes of requirements, which usually cause changes of boundary class's behavior, should have minimal impact on the system.

The way in which the communication between boundary and control objects is established in the Kraalingen class diagram does not allow for a flexible development. The boundary class has direct connection with the control class; an instance of the control class needs to be created in the boundary object so that the message simulate can be sent to this object. In the case that we would like to use another simulation system that provides similar functionalities, the system will not work. The reason is that the boundary object points directly to the SimulationController object and will not recognize any other object playing the same role unless the new controller object is referred to as SimulationController. Imposing the name of the control class is a considerable limitation. Coupling these two classes directly makes the system less flexible to changes and difficult to reuse.

The solution to this problem is defining one or a set of interfaces that the control class should implement; the behavior of the control class should be expressed using a well-defined set of interfaces. In our simple example, one interface is amply sufficient to describe the services that the control class offers. Figure 8-20 shows an interface defining the services of the control class SimulationController. As shown in this figure, the boundary class has an association with the interface ISimulationController. Therefore, the boundary object can reach data and behavior from any object created from a class that implements the ISimulationController interface. Thus, using an interface instead of a class opens the communication channels between the boundary object and any control object that implements the required interface.

Si mulationCantr oller

Figure 8-20. An interface defining the services of the control class SimulationController.

Si mulationCantr oller

Figure 8-20. An interface defining the services of the control class SimulationController.

The most important advantage of using an interface is that the boundary object does not need to know about the real control object that will receive the simulation parameters. If the simulation system is designed to function as an independent component, any such component can be plugged into a bigger system; the boundary object would communicate with all plugged-in components provided that they implement the required interface. Figure 8-21 shows an example of a boundary class associated with several control classes. Each of the control classes will provide a polymorphic implementation of the behavior defined by the interface ISimulationController.


^IPIant plant ^ISoil soil %IVVeather weather


^simul√Ęt e(Property properties)

0 0

Post a comment