Component Architecture

To be as flexible and extensible as possible GAL Framework uses component architecture of software design. Here will be described what does this term means in a context of project and how it influences library structure and usage at level of individual GRASS modules development.

Components and Interfaces

Using UML notation such an architecture can be shown as on a figure 1. There are four components connected to one interface with different relations. You may consider that components are groups of objects or classes which form compact sub-systems doing some job. For example a raster component which loads raster data from different files to memory or an analytical component which performs some computation over loaded data.

Figure 1: Component diagram of component architecture.

The components may own, use or implement certain interfaces which describes how these components would like to comunicate with others. On the figure, it's the Component 1 that declares (owns) an interface Interface which is indicated by stereotype <<reside>>. Component 1 and Component 2 use this interface (symbolized by dashed lines with arrow). Component 3 and Component 4 implement interface functions which is represented by solid lines.

Owning an interface means that component is responsible for its creation, destruction and registration in the system, using an interface means that the component may call one or more of interface's functions. In most cases, component which owns an interface is using it at the same time but there is only a single component owning a single interface. On the other side of interface stay components which implement them. They listen what components using interface say and respond to their requests. This implies that communication is entirely directed by components that use interface but subsidiary components can use other interface which could be implemented by superior components to reverse this subordination.

Slots

There is an abstraction over interface functions called slots that may be configured some way to specify which implementation will be executed. Sometimes you may want to execute just lastly registered implementation, sometimes you may want to call each of them, etc. The slot is ment to be a functor class that forwards interface function calls everytime it is evoked.

Components using interface can pick which implementations should be used. A question what available implementations are choosen when interface function is evoked could be separated into three cases. It is a little analogy to TCP/IP unicast, multicast and broadcast:

• 1 to N - Only a single implementation is choosen among others. It can be first idle component or lastly registered one. Example of such interface may be component which loads data from certain file format.
• M to N - A subset of registered implementations is choosen. Example of this are data processing components that are used to balance CPUs usage.
• N to N - All implementations are evoked and results (if any) are collected together. Example could be components that recieves error or debug messages. One displays them on a screen, second logs them to a file but they are all notified.

Different slot implementations abstract a mechanism of interface functions execution. There is static method callback and D-Bus RPC library slot implementations currently supported.

This layout brings flexibility to the framework because any component using particular interface can choose which implementation of an interface wants to utilize. Furthermore, any component can engage to implement an interface and lately it can abandon its obligation.

Component Manager

To allow public access to all available components and interfaces in the system, a common access point must be introduced. In this case, it is called component manager and it serves for components or interfaces registration as long as registration of interface implementations. Figure 2. shows simplified class diagram of relationships between the component manager, components, interfaces and slots.

Figure 2: Class diagram of component architecture.

Every component can then ask the component manager to recieve particular interface and use it or commit to implement it. Interfaces, when they are used, contains capabilities to manage all their implementing components so that component using the interface can decide which of them wants to use in manner presented before.

This brings a powerful extensibility to the system since components can be loaded from dynamic libraries like plugins on system start or even in runtime. Furthermore they can be spread over computer network or parallel environment by slot mechanism implemented using some RPC library.

Example

Conceptual example of component architecture applicability is shown on the figure 3. There is a component ModuleComponent implementing some GRASS module at the top which uses three different interfaces: IVectorLayerProvider for retrieving vector data, IRasterLayerProvider for accessing raster data and IMessageHandler for message display and logging.

Figure 3: Component architecture practically.

IVectorLayerProvider interface is implemented by two different components registered in the system. One of them shelters vector layer data in PostgreSQL database, the other provides for example data from MySQL database.

Raster related interface IRasterLayerProvider is implemented by two components too. First offers raster data from PostgreSQL database and second enwraps raster data in ordinary data files. This diagram should demonstrate that using this approach module component can obtain GIS data and it don't need to care where and how are these data stored.

When a module does what it wants with retrieved data and it needs to output some information to console, logs or GUI, it sends messages through IMessageHandler interface. In discussed example is this interface implemented by two components which forwards messages to CLI, GUI or write them to log files. This again demonstrates independence on outputted data presentation.

Discussion

You have no rights to see this discussion.