F. Balaguer, S. Gordillo*.
LIFIA-Departamento de Informatica,
Facultad de Ciencias Exactas, UNLP
CC 11 (1900) La Plata, Buenos Aires, Argentina
[fede,gordillo]@sol.info.unlp.edu.ar,
Tel/Fax: (54) (21) 228252
*also CIC-Pcia de Buenos Aires
1.-Introduction
The interaction among GIS applications and different kinds of systems (like databases, internet browsers, etc.) generates the need to solve difficult aspects at the implementation level. But, being application design critical for maintenance, reuse and extensibility, these additional problems should be also reflected in the design process.
Designing for reuse and extensibility usually requires interoperability: for example, if we want to reuse a legacy system adding spatial characteristics to it or if we need to use others systems not necessarily built with a GIS software. Our claim is that all these aspect must be (and can be) reflected during the whole design process to deal with them not only at the implementation level, but also in previous stages .
Design Patterns define design solutions to known problems, they constitute a way to record a recurrent problem, the core of the applied solution, its relationships and its responsibilities. Since Design Patterns are like templates, they can be used in many situations that are representing similar problems. Design Patterns are defined in [Gama95] where a vast catalogue explaining different design problems is presented. Also in [Gordillo97] it is shown how to use some existing Design Patterns to design GIS applications; some new ones have been defined specifically for this domain [Balaguer97].
In this paper we show how to use specific Design Patterns in GIS, for taking into account interoperability concerns by showing some examples. The first one, Decorator, allows us to extend a legacy system, built using an Object Oriented Methodology, adding spatial features to it. . Since the intent of the Decorator Pattern is to extend the functionality of objects in a dynamic way, it makes possible to reuse the legacy systems without re-defining it. Using this pattern, the new model (the spatial model) interacts with the legacy system to manage all responsibilities defined in the object model and it manipulates its own spatial responsibilities. The Mediator Pattern allows us to define an object that encapsulates the behavior specifying how a set of objects interact, decoupling in this way, the responsibility of objects from the interaction concerns. Reactor [Schmidt95] provides a simple way to support the demultiplexing and dispatching of multiples services, which are triggered concurrently by multiple events. We next describe the intent of each one of these patterns and give an example of situations in which they can be used.
2.-Design Patterns
In this section we explain different
problems that usually appear in the GIS field and their solutions in terms
of the application of previously mentioned patterns.
2.1.-Decorator
Problem:
Designers usually face some kind of
"hybrid" applications that deal with conventional transaction-based systems
and that must be upgraded to include spatial features. . However, ddding
behavior and knowledge to existing classes, produce a "dirty" solution,
since it mixes responsibilities of the application domain and the geographic
one. To extend a traditional (for example dbms based) application with
geographical features, we propose the use of the Decorator design pattern.
Solution:
Identify two underlying models: the conceptual
model and the geographic one. It makes possible to decouple the problem
into two different stages, thus limiting the concerns that designers simultaneously
have to deal with.
To extend the conceptual model to a geographic one, the solution is based on the construction of a decorator object which has the same protocol of the decorated one. The finall implementation of these messages is delegated to the decorated object (this object is known by the decorator). Also the decorator object implements its own set of messages which are implemented by itself. In this way, it is possible to add spatial behavior to conceptual objects. Since Decorators provide a flexible alternative to subclassing for extending functionality [Gamma95], the obtained solution is a design where both, conceptual and geographic objects can be manipulated, without re-define the whole application but generating interaction between both models.
Also, there may be geographic objets that do not have an associated conceptual one (because they only have spatial features) and therefore, they only belong to the geographical model. We define an abstract class, which groups the common behavior of those objects belonging to the GIS application model, plus those that have been wrapped from the conceptual model.
2.2.-Mediator
Problem:
It is necessary to use services
and geographical data from other applications. The usual strategy is based
on exporting and importing raw data from and to a server application. Suppose
a simple model to represent natural disasters such as storms, twisters,
etc.; a logical extension to this model could use a cadastral application
in order to calculate the economical impact in the affected area. The model
has to use the cadastral application as a server; this application imposes
its interfaces and protocols, finally the server application could be a
legacy system, afterward it could be unfeasible to modify or extend.
Solution:
Build an object which hides the
complex process of sharing data with the server application. This object
behaves following all steps (protocol) which are used to connect the client
with the server application. A hierarchy with different mediators could
be defined allowing to interact with different applications in order to
share their data and services.
2.3.- Reactor
Problem:
A geographical model has to be modified
or extended in order to allow connections to other applications. The model
could act like a server of data and services. Suppose you have to extend
a cadastral model with the objective to support remote calls or information
requests from other applications. The model has to be preserved from changes
related to connections and sockets services. The model has to be extended
to support different kinds of connections, allowing non OO applications
to interact with the geographical model, in order to request information
or services.
Solution:
Create an object which has the responsibility
for managing request events. It creates an specialized object in
order to satisfy each request. The Reactor pattern helps to decouple application-independent
mechanisms from application-specific functionality [Schmidt95]. The application-independent
mechanisms are reusable components that demultiplex events and dispatch
pre-registered event handlers.
3.-Conclusions
Patterns are the best way to record
designers experience solving recurrent problems, also they are the media
to reflect the state of the art of design in some fields. Interoperability
into GIS field has become an issue to solve because of complexity and diversity
of technologies applied on it.
We presented three design patterns
stressing problems related with interoperability in GIS domain such as:
extension of legacy models, communications between client and servers applications
(built from geographical model).
4.-References
[Balaguer97] F. Balaguer, S. Gordillo, F. Das Neves: "Patterns for GIS Applications Design". In the proceedings of Patterns Language of Programming 1997
[Gamma95] E. Gamma, R. Helm, R. Johnson, J. Vlissides: "Design Patterns. Elements of reusable Object-Oriented Software". Addison Wesley, 1995.
[Gordillo97] S. Gordillo, F. Balaguer, F. Das Neves. "Generating the Architecture of GIS Applications with Design Patterns" 5th ACM Workshop on Geographic Information Systems. Las Vegas, USA.November 1997.
[OGIS] Open GIS Consortium (OGC) (1996b), The Open GIS Guide -A Guide toInteroperable Geoprocessing, Available at http://ogis.org/guide/guide1.html
[Schmidt95] D.C. Schmidt, "Reactor: An
Object Behavioral Pattern for Concurrent Event Demultiplexing and Event
Handler Dispatching". (J.O. Coplien and D.C. Schmidt, eds), Reading, MA:
Addison-Wesley, 1995