Object - Component GIS: The new

Object - Component GIS: The new

Dr. David J. Maguire
Director of Products, ESRI
380 New York Street
Redlands, California, USA, 92373
Tel. 909-793-2853
Fax. 909-793-5953
Email: dmaguire@esri.com

Data models
The heart of any AM/FM/GIS is the data model which describes how facilities and processes in the real world are represented digitally in a computer. In comparison to other spatial applications, AM/FM/GIS systems tend to have data models which are highly structured and formalized. For example, in a typical water utility data model there is a clearly defined set of fittings (e.g., valves, hydrants, meters and back flow preventers), line types (e.g., canals, mains, and minor lines) and devices (e.g., aerators, clear wells, chemical injectors and generators) to be modeled. There is also very specific collection of rules and process methods which need to be encoded in the data model (e.g., valid valve types, add connectivity rules, delete processes, and draw methods).

Figure 1: AM/FM/GIS Data Modeling.

Over the last 30 years several different data models have been tried in AM/FM/GIS with varying degrees of success (Maguire, Goodchild and Rhind 199 1; Maguire and Raper 1992). Many data models (e.g., the CAD, Image and TIN models) are niche or application specific. In database-oriented AM/FM/GIS the gee-relational model has been widely and successfully employed for over a decade. In this model the geometry and topology of geographic features are stored in files, with the attributes in a database management system (DBMS). The link between the files and database is managed by AM/FM/GIS software. This model is geometry-centric, modeling the world as a collection of points, lines and polygons, with operations on the geometry encoded as separate procedures (scripts). The gee-relational data model has served AM/FM/GIS the - users well for many years because of its flexibility, extensibility and good performance. However, this approach has limitations for modeling the richness of geographic objects, and it can not be easily extended to support user- or domain-specific features. Also, recent advances now allow geometry and topology to be stored in commercial DBMS.

Figure 2: AM/FM/GIS data models and their applications.

To try to address these problems object-based data models were introduced. These allow the state and behavior of objects to be modeled in an integrated way in an AM/FM/GIS (Worboys, Hearnshaw and Maguire 1990). The state of an object can be thought of as the properties or attribute data of an object (e.g., for an electrical recloser [a type of isolation device or circuit breaker] it could be the coil size, interrupting capacity, current rating in kVA and nominal status). The behavior is the methods or operations which can be performed on an object (for a recloser it could be create, delete and draw methods, as well as network connectivity rules).

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.

Customization and extensibility
As stated earlier, one of the problems of first generation object-oriented GIS was that they had closed, proprietary data models and programming capabilities. Objectcomponents based on industry standard component models (COM and Java) offer the opportunity to use open approaches for AM/FM/GIS customization and extension. COM is particularly interesting because it is programming language neutral. Any COMcompliant programming language can be used to create a binary COM object. Examples include Visual Basic, Visual C++, Visual J++, Delphi, Powerbuilder and Developer2000. Visual Basic and its host-dependent derivative, Visual Basic for Applications (VBA), is especially interesting for application scripting and user interface development because of its highly interactive nature, ease of use, rich editing and debugging tools, forms-based approach to development, rich collection of user interface controls, and widespread use. For more advanced development many developers prefer VC++.

One interesting aspect of the COM standard is that objects derived from any source (AM/FM/GIS software vendor, third party application development consultant, user, and even Internet freeware!), can be plugged into the AM/FM/GIS at runtime and operate as full first class system objects. COM also offers a model for object persistence and object updates.

Data management
Historically, AM/FM/GIS have been implemented using hybrid or proprietary databases. This is largely because until very recently commercial RDBMS were unable to deal adequately with the special characteristics of spatial data (large data volumes, multiple dimensions, variable record lengths, requirement for specialist spatial operators and need for fast retrieval rate). Recent advances in AM/FM/GIS application server development and, on some platforms, object-relational DBMS (ORDBMS) now mean that it is possible to manage all AM/FM/GIS data in a single integrated DBMS. Many RDBMS and ORDBMS now provide support for Abstract Data Types (ADTs). This means that they can be extended to support spatial types (points, lines, polygons, etc.) and fmctions (specialist indexing, and query operators such as touch, inside and overlap). Facilities such as poles, pipes, reducers, and valves can now be stored in their entirety (geometric, topology and properties) as rows in conventional tables. Spatial extensions to SQL (most notably the emerging SQL3 multi-media standard) support spatial data definition and data manipulation.

Unfortunately, none of the major DBMS vendors has yet provided long transaction and versioning support, capabilities vital to providing multi-user access to continuous databases in design and work order environments. This task has been left to AM/FM/GIS software vendors who must either build their own database and design environment or extend the short transaction model of a commercial DBMS. Approaches which truly extend the DBMS are just emerging.

Managing AM/FM/GIS data in a standard DBMS offers many benefits:

All corporate data is centralized - this allows a single backup/ recovery and database administration process for an organization.
Indexing - on some database platforms AM/FM/GIS can utilize the native kernellevel database indexing. This offers reduced software development and maintenance costs and on some platforms performance advantages.
Security - DBMS offer high levels of security in terms of user access, referential integrity and long term data persistence.
Transactions - although there is a conspicuous absence of support for long transactions and versioning (as described above), the standard short transactional model of DBMS is usefil for attribute, and some types of spatial, update.
Platforms - commercial DBMS typically run on a range of hardware platforms and operating systems. By using the database to store spatial data AM/FM/GIS clients can take advantage of this platform independence.

Implications for AM/FM/GIS
The new breed of object-component GIS will in several respects revolutionize GIS. It is likely that they will quickly become the implementation norm for AM/FM/GIS because:

Object-components are based on standards - there are clearly defined and well understood standards which define component interfaces precisely.
Extensibility - because components are based on standards anyone (core developers, third party developers and end users) can create them and extend an AM/FM/GIS. New components can easily be created by specializing existing components. For example, a new type of street lamp could be created by inheriting the properties and behavior of an existing street lamp already defined in the system.
Run-time support - contemporary operating systems, Internet browsers and most popular applications (e.g., Microsofi Office) provide run-time support for components which means that a system can be extended while it is running. This makes components user-friendly and keeps system resource use to a minimum because new components can be loaded when they are required (e.g., components defining facility editing operations can be loaded into memory when a user starts the editing process).
Programming language neutral - this particularly applies to COM object components which can be created from almost any contemporary programming language. Many of the state-of-the-art Integrated Development Environments (IDEs - programming tools) provide support for COM and Java component creation and use.
Object behavior is in the data model - in the object-component model object behavior is moved from the user application to the system data model so it is fully recognized by the system and is available for all users.
Powerful design and analysis tools - many developers are already creating software components and as a consequence there is a rich collection of IDEs, CASE tools and specialist component suites. GIS software developers no longer have to create, for example, Table Grids, ReportWriters and Charting extensions to their core systems.

References

Maguire D J, Goodchild M F, Rhind D W 1991 Geographical Information Systems: principles and applications Longman, Harlow
Maguire D J, Raper J F 1992 Design models and functionality in GIS Computers & Geosciences 18 (4) 387-94
Szyperski C 1998 Component sof~are: beyond object-orientedprogramming Addison- Wesley, Harlow
Quatrani T 1998 Visual Modeling with rational Rose and UML. Addison-Wesley, Reading Massachusetts
Worboys M F, Hearnshaw H, Maguire D J 1990 Object-oriented data modelling for spatial databases. International Journal of Geographical Information Systems 4369-83