MATERIALS AND METHODS

Software components are sometimes compared to hardware components and the implication is that the composition of software components should be as easy as that to hardware components. When components are tightly coupled is hard to reuse them in other systems, since they depend on each other. Tight coupling also leads to monolithic systems, where one can`t change or remove a class without understanding its design and dependency of other classes. The maintenance of such systems becomes very hard. In contrast, loose coupling increases the probability that a class can be reused by itself and that a system can be well-read, modified and extended much easier.

Design patterns proposed by Gamma et al. (1994) plays a pivotal role, when objects come to interact with each other. Among the design patterns, mediator pattern provides decoupling between objects.

Fig. 2:	A bank system using mediator design patterns

Fig. 3:	Interaction diagram

With the mediator pattern communication between components is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, hence reduce the coupling. Nevertheless, this indirect message passing technique still leads to tight coupling because its controls are originated from the components and not from the mediator object.

The concern of interaction or collaboration between components can be found when evolution of software engineering come along way from machine-level language to procedural programming and then to object-oriented programming and now to component-based software development. An interaction is a set of activities that happen for a specific use case in a system, based on the ability of components (requires and provides services) to send messages to each other.

The interaction between components can be different from one system to another.

Fig. 4:	The Process of building up a system using attachment and mediator connector

However, we consider the interaction between components as a separate issue in our model. An interaction is a sequence of method calls to components connected to a mediator connector which can be defined in design as well as deployment phase. Fig. 3 shows the interaction of ATM, aBankCon1 and aBank1 components are interacting via mediator connector. There is no direct message passing in between these components.

Mediator connector: In this section, we introduce mediator connector as a composition operator for loosely coupled software components. The mediator connector is inspired by the mediator design pattern, in which the relation between components can be many-to-many or intersecting.

The composition of components using mediator connector is based on interactions between components as a subset of behavior in a system. The interactions are described in an attachment which is similar to Component Definition Language (CDL) in Koala component model (Van Ommering et al., 2000) or Architecture Description Language (ADL). The description of each interaction is a usage scenario of a potential way the system is used. An interaction description is also used to explore the logic of an operation, function and method.

Mediator connector initiates and coordinates method calls to the components and handles their results. Thus it encapsulates communication. From another point of view, mediator connector is similar to a communication hub. The control originates from the mediator connector which leads to total loosely coupling between components and mediator connectors. Figure 4 shows the process of building up a system by using mediator connector. Interaction diagrams uses only for definition of interaction in attachment (i.e., no coding in application).

For each specific use case in the system, the component interaction are described (conforming the attachment syntax) in the attachment.

Fig. 5:	Mediator connector design

Mediator connector will parse the attachment and build up the system by initiating all the components and the connections (method calls) described in each interaction. Each interaction (sequence of method calls) can be run by invoking the run method in mediator connector giving the name of interaction as in-parameter.

Implementation: In all interaction descriptions, the following objects are typical: interaction, components, messages (method calls) and possible parameters (in/out). Thus in order to implement our mediator connector as a framework, we designed the mediator connector as shows in Fig. 5.

The mediator connector is implemented in Java programming language which is as good as any object oriented language. In our composition method, a component is semantically a Java class with (i) provides services (public methods), (ii) code that implements the provide services, however components do not request services in other components. Actually, mediator connector will invoke their provide services externally. Figure 6 shows the class diagram of mediator connector and the relations between the classes.

Fig. 6:	Mediator connector class diagram

We may have multiple interactions in an attachment and a component or a method call repeats many times. To avoid instantiating and allocating a huge number of the same components as well as other objects, we use Flyweight design pattern which share a limited number of those objects. This can be detrimental to a system`s performance. Mediator connector does not directly instantiate components; instead it gets them from a factory. The factory first checks if it has a flyweight component that fits request specific criteria (e.g., a unique id and class name); if so, the factory returns a reference to that component. If the factory can`t locate a component for the specified criteria, it instantiates one, adds it to the pool and returns it to the client.

Since components are not allowed to send a message (method call) to the other components, components are wrapped in a ComWrapper (i.e., for each component in a system creates a ComWrapper object by ComWrapperFactory). This enables all the methods of a component to be invoked dynamically by ComWrapper using Java reflection.

Each interaction creates an Interaction object by InteractionFactory. Each interaction consists of a sequence of method calls to components with possible in-parameter(s) and out-parameter(s). Each method call is labeled by a class id and a class name, which indicates to which component it belongs to. Then for each method call definition, the mediator connector creates a MethodCall object by using MethodCallFactory, where the name of the method and a reference to the component it belongs to is encapsulated.

Fig. 7:	Part of constructor code of mediator connector

If a method call has in-parameters, Parameter object will be created by ParameterFactory and sets the references to indicate to which method call it belongs to. It also hold true for out-parameter.

The design of mediator connector makes it as a template which can be stored in a repository in the same way components are stored. The instance of mediator connector is created and deployed along with component instances.

Figure 7 shows the constructor code of mediator connector, where all factory objects are created.

Figure 8 shows the summarized of the code for building up structure of behavior in a system by parsing an attachment file. We have implemented a parser which is embedded in mediator connector. The parser receives an attachment file and creates proper objects with their references. An interaction can be run from anywhere (such as an event in the user interface), with minimum of code writing as shown in Fig. 8.

A bank system example: Figure 9 is an attachment for a bank system with possible interactions and configurations.

Using the above attachment, we can illustrate the bank system`s behavior by considering the operation of the Withdraw. The interaction starts when a customer intends to withdraw money from his account. The operation starts by calling the mediatorCon.run (Withdraw) as shown in the Fig. 8.

Then run method will get appropriate Interaction object which has a list of references to the MethodCall objects. Mediator connector goes through the list and for each MethodCall object it gets access to the reference of their ComWrapper object. Then each MethodCall objects will be sent as in-parameter to the execute method of their ComWrapper object.

In our Withdraw example the MethodCall objects are: ReadCard, getBankConId, getBankId and Withdraw.

Sometimes at the time of parsing (creation of method call instances) the reference of components to which they should be sent to, is not identified.

Fig. 8:	Part of the code for the bank system using mediator connector

Fig. 9:	A simple bank system example described in an attachment

Fig. 10:	System architecture using mediator connector as composition operator

This will be done by mediator connector at the run time by using the result from previous calls.

Figure 10 shows an application architecture composed by loosely coupled components. Components are wrapped in the wrapper objects, which can interact with mediator connector and it`s through user interface that we can interact with mediator connector.

Evaluation: The bank system example in the previous section demonstrates the feasibility of mediator connector in composing components based on their interaction definition. Composition of loosely coupled components makes it simpler for system maintenance and evolution (i.e. managing changes in both components and also mediator connector).

The most obvious advantage of the mediator connector is the use of attachment as the composition constructor. This provides a paradigm in software development, in which components can be easily unplugged and replaced due to the flexibility in defining their interaction independently. Our approach is also not far from the way the developers are used to develop a system (i.e. they don`t need to learn a new programming language in order to use mediator connector).

To measure the coupling between components, which is the main objective of this research, we have selected Coupling Between Objects class (CBO = Number of classes to which a class is coupled) metric developed by Chidamber and Kemerer (1994) to measure the static coupling between components in order to show that mediator connector provides loose coupling.

Coupling is defined as: two objects are coupled if and only if at least one of them acts upon the other (Fenton, 1994). In other words, since coupling is the degree of interaction between classes, the basic idea underlying all coupling metrics is very simple: count how many interclass interactions there are in the system. Multiple accesses to the same class are counted as one access.

Suppose there is a system including a set of components C = {C₁, C₂,...C_n}, where n is the number of components in the system. If Coup(i) is the CBO of C_i, then total CBO of components used in a system will be:

A component may have a group of classes working together toward a common end; a subsystem, which shouldn`t be counted as coupling compare to object classes. That`s why we designed a measurement framework, which is more accurate in order to measure the coupling between components using mediator connector.

According to above definition if we assume that T_before is the total CBO of components before composition in a system, T_after the total CBO of components after composition in a system not using mediator connector and T_mc the total CBO of components after composition in a system using mediator connector._.

Table 1:	Measurement values of CBO components in an aspect j control flow graph builder tool

Table 2:	Measurement values of coupling between components in a simple bank system

Then according to the CBO definition (multiple accesses to the same object are counted as one access) the total minimum coupling in a system using n components will be:

Finally the T_CBO in a system composed by n components can be defined as follow:

The result of applying above measurement framework on four case studies is shown in Table 1-4.

Measurements in all four cases show that the T_CBO using mediator connector in a system is always:

A system composed by components using mediator connector has only one object reference and that is a reference to the mediator connector instance. On the other hand mediator connector does not have any reference to the components. All connections for message passing will be created at runtime according to composition definition in the attachment. This leads to totally loose coupling between components and mediator connector, which increase reusability of components. This means that there is no need of changing, modifying, or customizing the components in order to reuse them in other system.

Table 3:	Measurement values of coupling between components in an MP3 player system

Table 4:	Measurement values of coupling between components in a display map system

Fig. 11:	Outline code of a bank system using exogenous connector (Lau et al., 2005)

Comparison with exogenous connectors: The implementation of a bank system using exogenous connectors in Fig. 11, demonstrates the creation of all component instances. This leads to that the (T_min) in a system using exogenous connector is always equal to n.

All levels of exogenous connector are tightly coupled to each other and also invocation connectors to components (computation units). Adding or removing a component change the whole structure of connectors in the system.

CONCLUSION

In this study we have presented mediator connector for composition of loosely coupled software components based on the interaction between components. We also have presented its definition, implementation and showing its feasibility by building a small bank system using loosely coupled components. Mediator connector uses an attachment where the interactions between components are described. The attachment we have presented is at the preliminary stage; however we are working on its format and syntax in order to make it well-formed as a generic framework for describing the components and the interaction between them. So far we have only used sequential composition and the connector we presented belongs to the deployment phase. We are studying the ability of our approach for design phase, where the composite components can be constructed and deposit in a repository. We believe that our approach is a novel development methodology towards the component oriented development paradigm.

ACKNOWLEDGMENT

This is an ongoing research at UPM, Malaysia and is supported by eScience Fund SF0704, Ministry of Science Technology and Innovation, Malaysia.