Design of a component architecture

We introduce firstly the component architecture designed based on the analysis of requirements previously introduced and the determined conceptual foundation, i.e. Webservices technology. Its static view is described by the component diagram and component description while the dynamic view is described by the activity diagram.

As the Figure 4.10 shows, the standardized component architecture of the FSPM integration system includes an integrative middleware (we named it FSPM integrative interface) that consists of two components: the ClientSideInterface and the ServerSideInterface. It resides in the middle of the ClientFSPM component and the ServerFSPM component to enable their integration by providing necessary interoperability. The component ClientSideInterface requires service from the component ServerSideInterface for the integration of different FSPMs. The cardinality ‘[0..1]’ at client side means one server may have zero to one client, and

‘[0..*]’ at server side means one client may have zero to many servers. This is a design based on the assumption about the possible integration of different FSPMs scenarios, i.e. one structural model with one or more functional models. The component ClientSideInterface includes six components, i.e. Client, Message, Graph, Coordinator, GraphConverter, and ConfManager. The component ServerSideInterface includes six components, i.e. Server, Message, Graph, GraphConverter, RetroactiveChecker and ServerFSPMRunner. The components Message and Client/Server are for message packing/unpacking and transmission.

The components Graph and GraphConverter are for the conversion of FSP data and information between different FSP data models. The component ConfManager at client side is about to allow the plant scientists to input the configuration setup for the integration based on biological knowledge. This might be a list of model records expressing the order of the model simulation, the name and network address of the model, its ‘main’ method, the times of its execution, and the names of its

characteristic properties (e.g. ‘interceptedLightAmount’). The component Coordinator at client side is about coordinating the simulation/execution of the different FSPMs by taking the configuration list set by plant scientists as reference.

By getting relevant member of message body (retroactive) through the provided interface MessageComponent of component ‘Message’, the component RetroactiveChecker is for determining if the client graph is needed to be converted for responding to the client. By getting the relevant members of message body (model, main_method, time) through the provided interface MessageComponent of component Message, the component ServerFSPMRunner is about to run the FSPM on server side through the provided interface MainMethod of the server FSPM. One remark is that the data flow in the integrated FSPM is mostly two directional. For example, the ‘message’ interface can be a provided interface of the component Message when the message is ready for the component Client to send. It can also be a required interface of the component Message when the response message is received by the component Client and ready for unpacking. We represent these two directional interfaces by one single (one directional) interface for the sake of simplification. Another remark is that the MessageComponent interface in the component ClientSideInterface includes a ‘two directional’ interface of the component Graph, a normal provided interface of the component ConfManager and a normal required interface of the component Coordinator. They refer to packing or unpacking of an XEG to or from the component Message, packing of relevant members of message body (i.e. model, main_method, time, and retroactive) to form the request message, and unpacking of ‘result_graph’ from response message for the use of the component Coordinator respectively. The MessageComponent interface in the component ServerSideInterface includes a

‘two directional’ interface of the component Graph, a required interface of the component ServerFSPMRunner, and a required interface of the component RetroactiveChecker. It refers to packing or unpacking of an XEG to or from the component Message, and unpacking of other relevant members of message body

(i.e. model, main_method, time, and retroactive) from the component Message respectively.

The static relationships are embodied by the usage dependency between the components. At the level of the FSPM integration system, the interface has two components, ClientSideInterface and ServerSideInterface. The former requires the FSPM integration service from the latter through the required interface FSPMIntegration, namely calls of the designed protocol.

• The component ClientFSPM’ depends on the service provided through the provided interface ClientGraph of the component ClientSideInterface,

• The component ServerFSPM depends on the service provided through the provided interface ServerGraph of the component ServerSideInterfacde.

• The component ClientSideInterface depends on the service provided through the provided interface FSPMIntegration of the component SeverSideInterface

• The component SeverSideInterface depends on the service provided through the provided interface MainMethod of the component ServerFSPM

• Plant scientists depend on services provided through the provided interface IntegrativeConfigurationEntry of the component ClientSideInterface and the provided interface MainMethod of the component ClientFSPM

At the level of integrative middleware, there are usage dependencies within the component ClientSideInterface and the component ServerSideInterface. In detail, the usage dependencies within the component ClientSideInterface are:

• The component Graph depends on services provided through the provided interface Conversion of the component GraphConverter and the provided

interface ManageComponent of the component Message (the component ConfManager also depends on the service through the latter interface).

• The component Coordinator depends on services provided through the provided interface CoordinativeReference of the component ConfManager and the provided interface ManageComponent of the component Message.

• The component Client depends on services provided through the provided interface Location of the component ConfManager and the provided interface Message of the component Message.

• The component Message depends on the service provided through the provided interface Coordination of the component Coordinator.

The usage dependencies within the component ServerSideInterface are:

• The component Graph depends on the services provided through the provided interface Conversion of the component GraphConverter and the provided interface CheckRetroactive of the component RetroactionChecker

• The component Server depends on the service provided through the provided interface Message of the component Message.

• The components SeverFSPMRunner, Graph, RetroactionChecker depend on the service provided through the provided interface MessageComponent of the component Message

Figure 4.11 The UML activity diagram for the integration of different FSPMs

The dynamic relationships between components are described by an activity diagram (c.f. Figure 4.11). In the diagram, the action flow starts from the RunMainMethod action in the ClientFSPM partition and the IntegrativeConfigurationEntry action in the ServerSideInterface partition, the former leads the FSPMSimulation action in the ClientFSPM partition, which then produces the ClientGraph object in the ServerSideInterface partition. The actions at the ClientSideInterface partition include IntegrativeConfigurationEntry, ClientGraphToXEG, GetMessageMembers, GetLocation, GetCoordinativeReference, PackMessage, SendMessage, ReceiveMessage, UnpackMessage, Coordinate, XEGToClientGraph, GetClientGraph, the involved objects are Configuration, ClientGraph, XEG, MessageMembers, Location, CoordinativeReference, UpdatedMessage, MessageMembers, UpdatedXEG. A decision is made over the result of the action Coordinate, which effectively coordinates the simulation of different FSPMs. At the ServerSideInterface partition, the actions include ReceiveMessage, UnpackMessage, CheckRetroactive, RunMainMethod, XEGToServerGraph, ServerGraphToXEG, PackMessage, RespondMessage, the involved objects are Retroactive, MainMethod, XEG, ServerGraph, UpdatedServerGraph, UpdatedXEG. A decision over the result of the action CheckRetroactive is made. The action flow ends when the client FSPM simulation is finished, the UpdateMessage is determined as unexpected, or the result of the action CheckRetroactive is determined as non-retroactive.