Object - Component GIS: The new
Object-components
Early, first generation object-oriented GIS were built using C/C++ and suffered from
several limitations, notably: difficulty of sharing parts of the system (it is very difficult to
share binary C++ components, most attempts have only shared source code), problems of
persistence and updating C++ components without recompiling, lack of good modeling
languages and tools, and proprietary interfaces and customization tools. To counteract
these and other problems many software engineers have adopted component-based
approaches to system development. A software component is a binary unit of reusable
code (Szyperski 1998). The key to the success of components is that they implement in a
very practical way many of the object-oriented principles now commonly accepted in
software engineering. Components encapsulate behind a well-defined interface the
manipulation methods and the data which characterize each instantiated object. This
promotes structured and safe system development. Components facilitate software reuse
because they are self-contained building blocks which can easily be assembled into
larger systems. They also support inheritance and polymorphism. Inheritance is the
ability to re-use code in other components by including a reference to another object's
state and behavior. For example, a new type of water valve can easily be create by
overwriting or adding a few properties or methods to an existing type of valve that is
similar. Polymorphism describes the process whereby each object has its specific
implementation for operations, such as draw, create and delete. One example of the
benefit of polymorphism is that an AM/FM/GIS can have a generic object creation
component that issues generic object create requests to be processed in a specific way by
each type of object class factory (e.g., gas pipes, valves and service lines).
In a nutshell an 'object-component' approach is superior to an 'object' approach for
AM/FM/GIS because it adds a framework for anyone to extend a data model. In the
basic object model approach only the original AM/FM/GIS vendor has complete
customization capabilities and is free from performance and functionality bottlenecks.
Also, because of the closed nature of object implementations users are bound to
proprietary macro languages when they want to undertake customization. With the
object-component model, users extend the data model with exactly the same technology
as the AM/FM/GIS vendor programmer. As a consequence, users have more options and
their objects will perform just as well. To the user, there is absolutely no difference
between the AM/FM/GIS vendor supplied objects and the custom objects.
Several different, but overlapping standards have emerged for developing and sharing
components. For building interactive desktop applications Microsofi's Component
Object Model (COM) is the de fac?o standard. On the Internet, and possibly as a future
serious rival to COM on the desktop, Javasoft's Java Beans is viable technology. At a
coarser grain appropriate for application level interoperability the Object Management
Group (OMG) has specified the Common Object Request Broker Architecture (CORBA).
Data modeling
The world of data modeling has received a recent boost by the development of the
Unified Modeling Language, UML (Figure 3). This combines an entity-relationship
approach to modeling with an object-component architecture. UML can be used to
specify component interfaces and relationships.
Figure 3: An explanation of UML nomenclature.
The boxes are classes, the lines are
relationships. An abstract class cannot be used to create objects, but is useful in defining
subclasses. CoClasses can directly create objects, ordinary Classes can only be created
indirectly. Associations are relationships between classes, Type inheritance defines
specialization of subclasses, Instantiation specifies that one class has a method to create
the other, Aggregation defines a group of classes, Composition is a stronger form of
aggregation, and Multiplicity defines the number of objects in the relationship. Finally, a
wormhole is a diagrammatic technique to link parts of a master diagram. For more
details see Quatrani (1 998).
Several Computer Aided Software Engineering (CASE) tools have been developed which
can create UML diagrams (graphical representations of data models) and can engineer
both database schema and code. The schema can be implemented in commercial
relational database management systems (RDBMS) such as Access, DB2, Informix,
Oracle, SQL Server or Sybase. Additionally, the CASE tools can create code in the form
of COM objects for implementing rules and object behavior. Diagrammatically this
approach is shown in Figure 4.
Figure 4: Use of a CASE tool for oqject component modeling.
This type of methodology can be implemented for AM/FM/GIS systems using standard
products such as the Visio and Rational Rose CASE tools. All that is required is that the
products have open interfaces to programming tools and databases, and support UML and
other related industry standards.
