GISdevelopment.net ---> GITA 1999 ---> System Architecture

Building dynamic network models with GIS software components

Dr. Erik Heel
Environmental Systems Research Institute
380 New York Street
Redlands, CA 92373
Emailt: ehoel@esri.com


Software technology
Software technology continues to develop at an ever-increasing pace. Pronounced technological advancements are being made in the areas of object-oriented analysis, design, and implementation infrastructure. The ultimate goal of such advancement is to leverage technology in order to create more flexible and robust systems with lowered development investment. An increased level of software reuse is directly correlated with lowered error/defect density and increased programmer productivity (Basili, V., Briand, L., and Melo, W., 1996). Object-orientation has promised these gains for well over a decade, but until recently it has been particularly difficult to achieve such results.

  1. Evolution of Obiect-Orientation
    Object-orientation is undergoing an evolution that has been characterized as having three fundamental phases, termed the first, second, and third waves (Box, D., 1998(1)).

    1. First Wave
      The First Wave of object-orientation began in the late 1980s. This period can be characterized as focussing on the concepts of classes - namely the bundling of state and behavior. Objects belong to classes and clients manipulate objects via class-based references. Implementation inheritance was the dominant characteristic of this wave. A programmer assembled classes into libraries that were often documented in a manner that assumed that the end user would access the source code as the final reference. The technical downside of this class-centric approach is tight coupling of the class library and the client application classes. This type of implementation inheritance is often termed white-box reuse you must have knowledge of the internals of the base class in order to ensure integrity of the derived class. The class-centric approach also suffers from problems related to portability; class libraries differ by compiler and platform, thus precluding a client application built using a different compiler from linking against the class library. Additionally, this approach also suffers from the lack of binary encapsulation; the client compiler must know the class layout in order to instantiate it or make method calls. We direct the motivated reader to Box, D., 1998(2) for further details.


    2. Second Wave
      The Second Wave of object-orientation began in the middle 1990s. This period can be considered as advancing the concept of components (or interface-based development). Components and their associated frameworks enhance modularity by hiding implementation details behind stable and well-defined interfaces (Fayad, M,, and Schmidt, D., 1997; Wiederhold, 1998). This reduces coupling and retains the benefits of polymorphism. This is a refinement of the classical 1980s object-orientation as the interface is now the primary mechanism for expressing type relationships. Interfaces are separate from implementation - the "what" and the "how" of an object are two distinct concepts. The developer views implementation as a black box; all implementation details are opaque to the client of an object. Essentially, implementation reuse is binary reuse - the client does not need to know any of the inner details of the component, nor does the client know or care which language was used to implement the component.

      The key point to building reusable components is black-box reuse, which means the piece of code attempting to reuse another component knows nothing, and needs to know nothing, about the internal structure or implementation of the component being used. In other words, the code attempting to reuse a component depends upon the behavior of the component and not the exact implementation. Frameworks that were key to the adoption of interfaced-based development include Microsofi's COM (Microsoft, 1994), Object Management Group's CORBA (Object Management Group, 1995), and Java's RMI (Arnold, K., and Gosling, J., 1997).


    3. Third Wave
      The Third Wave of object-orientation is currently in its infancy. You can characterize this wave as focussing on stateless objects and transaction monitors (which support scalable distributed component architectures). You can logically model an object as state and behavior, but the implementation must explicitly distinguish between the two. Developers can leverage this new infrastructure (concurrency, error recovery, load balancing, and data consistency) to decouple the virtual function pointers (i.e., behavior) from the object state. Microsofl Transaction Server (MTS) is an example of such an infrastructure. Another notable example is the Sybase Jaguar Component Transaction Server.

      These technologies may prove to be the future of object-oriented software. At present, they are evolving technologies that do not yet have the maturity necessary for incorporation into high-end AM/FM/GIS. An important consideration is that AM/FM/GIS systems based upon component architectures will be well positioned when stateless objects are ready for widespread commercial implementation.
General system requirements
There are numerous general requirements of any AM/FM/GIS solution. These range from some that would be expected of any state-of-the-art GIS to those that would typically only be necessary in a highend AM/FM/GIS system. It is interesting to note that robust support for industry standards is one of the key meta-requirements that arises in most if not all of the following general requirements. The list of requirements for an AM/FM/GIS system includes but is not limited to the following:
  1. Standard RDBMSS
    It is no longer commercially viable for a GIS software vendor to support the persistence of data inside a proprietary database. End-users now demand that data be persisted inside industry standard commercial relational database management systems (RDBMS) such as Oracle, SQL Server, Informix, Sybase, and DB2. Standard commercial RDBMSS afford end-users the safety of having their key asset (i.e., corporate data) stored in a technology that is independent of their AM/FM/GIS software provider. By using commercial RDBMSS, you realize benefits such as the centralization of all corporate data, robust security models, platform independence, backup utilities, and other administrative tools. The AM/FM/GIS vendor adds value to the RDBMS by building infrastructure (or middleware) that manages geometric types and provides services such as optimized spatial storage and indexing mechanisms and spatial and topological operators and query capabilities.


  2. Standard Customization Languages
    Many legacy systems require the end user or third party developer to use proprietary scripting languages to customize the AM/FM/GIS system. Proprietary languages suffer from several fundamental defects. These include small pools of expensive developers expert in the proprietary language, lowered language functionality when compared with standard languages, the inability to directly incorporate soflvvare components, and the absence of a rich visual programming environment. Examples of industry standard languages are C++, Visual Basic, Delphi, and Java. The end user benefits from standard programming environments in several ways. The primary benefit is the ability to extend the component object model in exactly the same manner as the AM/FM/GIS vendor programmer (provided the language supports the underlying component framework, as most now do). This gives the customer the advantages of exceptional flexibility in customization and very high performance. Other advantages include the availability of better tools, a market filled with third party components, significantly larger pools of qualified developers, and the security of not being beholden to odd proprietary languages.


  3. Standard Visual Modeling Tools
    In order to craft sophisticated solutions with industry standard languages and database technology, it is necessary for the AM/FM/GIS software provider to support some form of visual modeling tools. Such visual modeling tools are used at the analysis and detailed design stages of the software engineering process. As was the case with database technology and customization languages, it is also very desirable for industry standard modeling tools to be utilized for this goal. Currently, there are numerous third party visual modeling tools that provide direct support for developing object-oriented systems (e.g., Rational Rose, Visio Professional, Paradigm Plus, and others). The essential requirements here are support for the Unified Modeling Language (or UML - lingua franca of object modeling; see Rational Software, et. al., 1997 for further details), and open modeling tool persistence mechanisms such as Microsofi's Repository. Repository is a technology for defining and populating information (meta data) models (Bernstein, Sanders, Harry, Schutt, and Zander, 1997). Rather than using a limited and proprietary modeling tool, the end user should be able to select a commercial visual modeling tool and utilize it for their object modeling as well as database schema design. Additionally, there should be mechanisms that allow the generation of source code (again in industry standard languages such as C++, Java, Visual Basic or Delphi) that is driven by the UML object models.


  4. Long Transactions and Optimistic Versioning
    Given the multi-user, job-oriented nature of AM/FM database updates, support for long transactions and optimistic versioning is a fundamental requirement. Traditional row locking is not sufficient; rich object models with high degrees of interconnectivity increase the impact of locking a row in the database. Automatic conflict detection and resolution are additional requirements for long transaction and versioning support.
Geographic objects
The traditional GIS data model - the GeoRelational model - uses a row in a tabular database to represent a geographic entity such as a parcel, road, or manhole. In this model, the feature type is defined purely by the data - a parcel is no different than a building, a road no different than a stream. Each feature is composed of geometry and a collection of attributes. For sophisticated development, this model is limited because the client may only loosely bind behavior to the data.

In contrast, an object-oriented GIS model provides a means to encapsulate behavior with the feature data. This tight coupling of data and behavior is what makes the system truly object-oriented. It allows applications to define and work directly with their actual domain objects (e.g., parcels, roads, or 570 manholes) instead of just rows in a database. We wiIIterm such objects Geographic Objects. Geographic Objects, when properly constructed on a component architecture, allow the user to create custom domain objects that are no different in performance or range of functionality than the GIS vendor provided objects. Additionally, Geographic Objects supply default behavior for the most common tasks such as editing and display. The user may focus only on aspects of the Geographic Object that they wish to customize, and rely upon the default behavior for the remainder that they do not wish to customize. In the remainder of this paper, we will use the terms Geographic Object and feature interchangeably.

Network modeling
There are many difficult problems that a data modeler encounters when building sophisticated AM/FM networks. At a very high-level, the largest problem areas include:
  1. Topological Relationships
    Within AM/FM/GIS systems, many (if not most) of the features participate in "active" topological networks. Rather than relying upon end-user provided solutions to maintain these topological relationships, the fundamental infrastructure of the system must handle this requirement (database integrity as well as interactive topological editing).


  2. Complex Network Topologies
    In certain AM/FM domains such as electric and telecommunications, it is frequently necessary to model more sophisticated features which have complex internal network topologies. As an example from the electric distribution domain, switchgear (such as the S&C PMH serie$ see S & C Electric Company, 1994) may have five associated network junctions, and four network edges arranged internally in a star configuration. Rather than represent the switchgear feature as a single network junction, it is desirable to consider that collection of network junctions and edges as corresponding to a single feature.


  3. Complex Relationships
    Within sophisticated AM/FM/GIS object models, it is necessary to support user-definable relationships between features. These relationships differ from the implicit topological relationships that the system should also maintain. These relationships can come in two primary flavors; associations, and composite relationships. Associations are bidirectional, semantic connections between two features. Composite relationships are semantically stronger than associations as composite relationships define a one-to-many relationship between an origin feature and a destination feature. The origin feature controls the lifetime of the destination feature. You may use composite relationships to construct composition-based features - features that are composed of other features (e.g., a transformer bank and a collection of transformer units).


  4. Complex Model Maintenance
    In order to maintain the integrity of sophisticated AM/FM/GIS object models, it is necessary to provide mechanisms that support object validation without resorting to database-specific (and unportable) triggers. Database triggers are unportable and are very difficult to debug in large systems. The validation infrastructure must also facilitate relationship-based event notification.
Generic network features
In order to architect an effective AM/FM/GIS solution, the GIS vendor should provide a collection of generic network features to support complex and dynamic networks. These data objects are implemented as software components that can be persisted within a RDBMS. The end user or third party developer must be able to extend this object model for their specific domain or company requirements.

An important characteristic of this network model is support for a dual view of a network: the individual features which are manifest on the map display and a logical network which represents all of the seen and unseen elements of a network.

A logical network is a collection of topologically connected nodes and edges and represents the complete topology of a network. With a logical network, you can perform rapid trace analysis on very large networks.


Figure 1. UML model of network elements and features.


A network feature can be associated with one or many elements in a logical network. This gives us the infrastructure to model complex network topologies such as those found within a switchgear. You update logical networks by editing network features. These features contain the behavior to intelligently synchronize their physical representation on the map with their underlying topology in the logical network..

This is a taxonomy of the types of network features:
  1. SimpleJunctions
    A SimpleJunction is a feature that is associated with a single node in a logical network. You connect a node to zero or more edges, and an edge must be connected to two nodes. An example of a SimpleJunction in a water distribution network would be a valve.


  2. SimpleEdges
    A SimpleEdge is a feature that is associated with a single edge within a logical network. Another network feature cannot be inserted within a SimpleEdge without splitting it. An example of a SimpleEdge in a water distribution network would be a lateral.


  3. ComplexEdges
    A ComplexEdge is a feature that is associated with any number of edges within a logical network. These edges must be arranged in a chain configuration with a single junction between each pair of edges. One may logically subdivide ComplexEdges without subdividing the feature itself. This is in contrast to SimpleEdges that may not be logically subdivided. An example of a ComplexEdge in the water distribution domain would be a water main.


  4. ComplexJunctions
    A ComplexJunction is a feature that is associated with a collection of junctions and edges within a logical network. The edges and junctions must be connected and may be arranged in any topological configuration. In effect, you may arrange the nodes and edges associated with a ComplexJunction to form a nontrivial network themselves. An example of a ComplexJunction in the electric distribution domain would be a switchgear.
Feature customization
Utilities demand considerable freedom to configure and customize data models to meet their domain and corporate requirements. To meet this goal, network features and other components must support a spectrum of customization that allows simple modifications to be parametrized and more complex behavior to be programmed. These are the techniques available for tailoring a system:
  1. Configuration
    As the first stage of an effort to customize the features in a system to a client's needs, you may configure several different aspects of the system without performing any programming. These are some of the supported techniques:

    1. Subtypes
      At some stage of the object modeling process, it becomes necessary to "lump" rather than "split" features. This is often the case when features share the same sets of attributes, similar behavior, as well as similar relationships to other features. For example, in the water distribution domain, it is usually not necessary to subclass a Lateral feature into FireService, WaterService, or IrrigationService. Instead, you may choose to stop subclassing at the service level and rely upon an attribute that also functions as a subtype for purposes of controlling the behavior or relationships that may exist between this feature and other features.


    2. Default Values
      Based upon the type (or more properly "subtype") of the feature, it should be possible to speci~ a default value that any given attribute may take. Thus, for each attribute within a subtype of a feature, it should be possible to specifi a default value. You should be able to perform this specification without having to resort to any programming.


    3. Validation Rules
      Related to concepts that were expressed previously, namely features, subtypes, and attributes, it should be possible to specify and establish validation rules that maybe fired at user-specified times during the update of the AM/FM/GIS database. Validation rules allow clients and third-party configures to specifi permissible attribute values, allowable relationships between features (both topological and nontopological), and spatial relationships. In state-of-the-art systems, you should be able to speci~ such rules without any programming.


    4. Relationships
      As was mentioned previously, aside from inheritance, the other fundamental modeling construct that can be utilized in creating sophisticated and powerful object models are relationships. Relationships, in the UML parlance, are defined as associations and compositions (aggregate relationships are the semantic equivalent of associations). As is the case with subtypes, default values, and validation rules, it should be possible for the end-user to specify the permissible inter-feature relationships either with the visual modeling tool or some other non-programmatic mechanism. In establishing these relationships, the enduser must be able to specifi the source and destination class of feature, as well as the cardinal ities and role names, and persistence mechanisms for such relationships (i.e., join tables or embedded foreign keys).


    5. Database Schemas
      Database schemas have typically been the focus of previous generation visual modeling tools. It is necessary to be able to specify database schemas in conjunction with the development of object models in creating powerful and flexible solutions. The end-user should be able to specify these database schemas (and any other necessary supporting tables) either through the modeling tool or via other nonprogrammatic mechanisms.

  2. Customization
    You can accomplish a second level of customization by programming software classes that extend the generic feature model. You would utilize composition and encapsulate a generic feature within your custom feature. These are some of the custom behaviors best implemented by writing software code:

    • Drawing - Control how the feature is rendered on the screen.
    • Network topology - Establish different topological configurations of the network junctions and edges associated with a feature.
    • Property inspectors - Facilitate custom inspectors that allow attributes and relationships to be viewed in non-default manners.
    • Class variables - Create variables that are shared among all feature instances of a specific class (e.g., a class variable that indicates the oldest valve among the collection of all valve features in the system).
    • Event handling - Provide developers "hooks" in which to specify additional behavior that is executed at established events that may occur during feature edit.
    • Connection points - Specify Visio-like connection points that may be located either on, internal to, or external to the geometry of a feature. These connection points may be used as snapping targets within the feature editor.
    • Fully custom behavior - Allow any other additional methods or properties to be associated with a feature that are not provided by default by the AM/FM/GIS system.
Domain frameworks
Finally, in order to leverage a component architecture, it is necessary to provide a framework of domainspecific features (components) arranged in an object model that accurately and effectively models the real world. Rather than requiring the end-user to model their domain from the ground up (or arrange for a third party to do the same), the AM/FM/GIS system should have available a framework of components which may be used as an advanced starting point for such an effort. Ideally, all that would be required in order to deliver the working solution would be a modest amount of configuration and customization. Figure 2 provides an example of an abbreviated collection of components that model real world entities in a water distribution system. Note that these components leverage the generic components provided by the underlying AM/FM/GIS (i.e., the Feature, ComplexEdge, and SimpleJunction components).


Figure 2. UML model of a very abbreviated Water Distribution Framework.


Conclusion
Component architectures, sophisticated customization opportunities (both through configuration as well as coding), standard languages, standard visual modeling tools, standard database technology, as well as sophisticated infrastructure and generic functionality are the hallmarks of a modern AM/FM/GIS system. The benefits of leveraging these standard technologies are greater economy, superior tools, high performance and wider functionality. Additionally, all developers (GIS vendor, third party, and end user) are free to concentrate on their core competencies and collectively build systems that better reflect the real world.

In our judgement, the component architectures based upon frameworks such as COM or CORBA are the most suitable for development of large-scale commercial AM/FM/GIS systems. Systems that ignore modern software trends will suffer the fate of forlorn wandering spirits, as they will be unable to keep pace with the rich collection of tools and components that are continually being released in the commercial marketplace.

References
  • Arnold, K., and Gosling, J., 1997: The Jma Programming Language. Second Edition, Addison-Wesley, Reading, MA.
  • Basili, V., Briand, L., and Melo, W., 1996: How Reuse Influences Productivity in Object-Oriented Systems. Communications of the ACM, (39) 10, Association for Computing Machinery.
  • Bernstein, P., Sanders, P., Harry, B., Shutt, D., and Zander, J., 1997: The Microsoft Repository. Proceedings of the 23rdVLDB Conference, Athens, Greece.
  • Bichler, M., Segev, A., and Zhao, J. L., 1998: Component-based E-Commerce: Assessment of Current Practices and Future Directions. SIGMOD Record, (27)4, Association for Computing Machinery.
  • Box, D., 1998( 1): The Third Wave. Microsofi Systems Journal, ( 13) 1.
  • Box, D., 1998(2): Essential COM. Addison-Wesley, Reading, MA.
  • Fayad, M., and Schmidt, D., 1997: Object-OrientedApplication Frameworks. Communications of the ACM, (40) 10, Association for Computing Machinery.
  • Microsofi, 1994: The Component Object Model Specljication. Version 0.9, Redmond, WA.
  • Object Management Group, 1995: The Common Object Request Broker: Architecture and Specl~cation. Version 2.0, Object Management Group, Framingham MA.
  • S & C Electric Company, 1994: S & C Manual PMHPad-Mounted Gear. Descriptive Bulletin, S & C Electric Co., Chicago, IL.
  • Rational Software, et. al., 1997: Unl~edModeling Language Specljication. Version 1.1.
  • Wiederhold, G., 1998: On Soflware Components: A New Paradigm. International Workshop on Component-based Electronic Commerce, The Fisher Center for Management and Information Technology, U.C. Berkeley.
© GISdevelopment.net. All rights reserved.