This paper presents software engineering strategies for designing and building reusable Geographic Information System (GIS) application software. With proper planning and execution, these methodologies will bring significant cost savings and efficiency gains to one of the most expensive aspects of customizing GIS software tools. Organizations employing contractors to develop software applications, as well as application developers, will both benefit from these methodologies. This paper does not discuss the Microsoft component object model (COM), which Esri will utilize to provide application developers with access to Esri product objects assembled by Esri. The new Esri product direction based on the Microsoft COM paradigm will greatly enhance the third-party application development environment in the future, and it is also consistent with the reuse strategies discussed in this paper.

The paper presents time proven methods and tools for creating, managing, and accessing a library of reusable software components. In addition, cost-benefit guidelines are developed to help an organization decide when the benefits involved in implementing reusable coding procedures outweigh the implementation overhead. Specific recommendations are made for code documentation practices, software design, and management procedures that encourage and result in successful code reuse practices. One of the major challenges of building reusable software in the GIS environment are the high dependencies of the application on a specific "client-dependent" data model. The paper will address how to deal with specific application data dependencies and engineer software components for portability across different data models.

 Software component reuse is the software engineering practice of creating new software applications from existing components, rather than designing and building them from scratch. Reusable components can be requirements specifications, design documents, source code, user interfaces, user documentation, or any other items associated with software. All products resulting from the software development life cycle have the potential for reuse.

Reusable components are easier to maintain (over time) and typically have a higher quality value (more robust and fewer errors). The practice of component reuse supports the motivation for development of specialized GIS applications. The business case is reduced application development time, reduced application cost, and improved application quality. Assuming the motivation for use and development of specialized GIS application software is one or several of the following:

• To reduce time
• To reduce effort
• To save dollars or earn dollars
• To improve quality

Then, the easiest way to accomplish these goals includes one or both of the following: 

• Improve staff effectiveness (produce more with less through applied use of technology or incentives)
• Decrease production workload (produce less new output by reusing previously produced materials to meet an equivalent or increased demand)

Examples are provided below.

• Replace manual drafting of multiple copies of a map with reprographics technology or create a reusable electronic map and produce copies by replotting the data (reuse of previously produced data)
• Replace production of GIS application source code for multiple applications (by potentially multiple staff) by sharing and reusing software components of previously produced applications

Custom applications built in conjunction with geographic information systems are prime candidates for component reuse for the following reasons:

• Custom GIS applications and interfaces are usually procured, designed, and built as "one-of-a-kind" systems.
• An "out-of-the-box" or "Commercial Off-The-Shelf (COTS)" GIS, as it exists in the industry today, is not tailored to a specific use without significant data configuration.
• Data for each custom application is unique.
• GIS is often too complex for inexperienced users.
• There is an increasing demand for spatial data analysis among the non-GIS educated population and businesses.
• There are many similarities among custom application requirements for all GISs.

 What makes these items reasons for seeking or implementing component reuse practices?

The answer to this question lies in the fact that many businesses will need to perform or contract for the customization efforts and provide a means of reducing or overcoming the complexity of GIS. Cost is the bottom line. Component reuse can significantly reduce the cost and time requirements of GIS implementation regardless of who performs the customization. The greater the amount of customization performed by an organization, the higher the return on investment in reuse practices. Companies, such as Convergent Group, can pass very significant savings on to clients building customized applications due to the shear volume of the specialized application and component library development performed.

Traditionally, GIS product vendors, such as Esri, have excelled in providing "tool boxes" for processing geographic data. Because of the uniqueness of the data sets required in each domain, the tool box approach has traditionally been, and will continue to be, the most successful way to bring "shrink-wrapped," COTS software solutions to the market. COTS software in the GIS market primarily consists of the "toolkit" and not end-user applications. The "shrink-wrap" COTS approach is most suitable for desktop applications, such as word processing, spreadsheet, and communication applications, such as e-mail and Web browsers.

However, GIS tools with many diverse applications are often too complex for users not using the technology on a daily basis. The users of the software tools must acquire, combine, and apply specialized education and knowledge in the use of the tools, along with their knowledge of the particular business domain, to arrive at the desired solution. The difficulty in acquiring and maintaining a diverse knowledge base, coupled with their complexity, has led to the popularity and demand for creating specialized GIS applications focused on a particular business requirement and a unique data model. Thus, the complexity of a GIS tool box is often simplified for a particular use through GIS application development. 

It is in these specialized applications where component reuse becomes most beneficial. Rather than developing each unique GIS application from scratch, it is much more cost effective (for both buyers and service providers) if application developers can utilize previously created components. Specialized application development then becomes a lower cost practice of matching similar requirements, finding and assembling the components in a way that provides the solution to a unique requirement.

 Another factor driving the industry-wide reuse initiative is simply the volume and complexity of computer information and tools needed to process that information. As more and more corporate information databases continue to be developed, the user community continues to grow, as does the need for increased and widespread spatial analysis tools. At the same time, the complexity, depth, and volume of GIS processing tools continue to grow. It is no longer practical for everyone who can benefit from spatial analysis capabilities to obtain and master the use of the highly specialized GIS software tools.

 The demand for intuitive, simple-to-use, yet highly specialized and sophisticated, GIS applications continues to be the challenge facing GIS technology providers today. Again, component reuse offers significant cost reductions and affordable solutions for deployment of customized spatial analysis applications. Deployment of customized GIS tools and capabilities to a user community primarily educated in their own business domain, and not on GIS technology, will continue to be a requirement that promotes reuse practices.

 Companies specializing in GIS application development, such as Convergent Group, are finding that component reuse techniques can significantly reduce the development time and costs for clients. Due to component reuse disciplines, companies are now able to contract for or build affordable, easy-to-use GIS applications that are customized around their unique information infrastructure.

By lowering the cost of specialized GIS applications, component reuse indirectly helps deploy GIS to users who cannot afford the luxury of time or money to becoming highly trained and educated in spatial data processing tools. 

Software reuse is a relatively new approach in the GIS industry, and, for the most part, it is not yet common practice in this industry today. The software engineering community, as a whole, has adopted reuse and embraces the approach wholeheartedly. The "data centric" nature and relative immaturity of the GIS applications market are reasons the GIS industry has been slow to adopt reuse practices. The rising cost of creating new GIS applications and of extending existing GIS applications is the catalyst motivating the industry towards software reuse consideration.

Software reuse is not a practice that will just happen because it sounds like a good idea. Developing or utilizing reusable components requires an up-front investment, up-front planning, established reuse techniques for building and using the components, effective detailed documentation of the components, and an indexing system or search engine to enhance access to the components for the software development community.

 The future of software engineering for economic reasons will become the art of assembling components, rather than the art of building components, as it is today.

• Frequent architecture and system changes.
• Organizational and cultural issues; reuse requires a fairly drastic change.
• Lack of automation tools to assist with specific reuse mechanisms.
• Higher up-front investments.
• Organization size and amount of application development performed will be proportional to payback. Smaller organizations will not benefit as much from code reuse.
• Too large of a project or effort is often attempted initially.
• Experience has shown that it requires three to five years to implement a formal reuse program across a large corporation.
• Initially, the end-to-end software life cycle will be longer.
• Lack of component indexing and searching mechanisms.
• Developing a componentization scheme or architecture reflecting which components need to be built and which components should be acquired from other providers in the industry. If a component is expected or will be available soon from an outside source, then a wait versus build decision needs to be made.

 Characteristics Needed for Qualification as a Reusable Component

In order for a component (specification, design, code) to be reusable, it needs to have certain qualities that contribute to its reusability. Reusability is defined as the extent to which a software component can be used with or without changes in multiple software systems, versions, or implementations (McClure 97). A list of those characteristics generally sought after to promote reusability as presented by McClure are as follows:

• General with build-in adaptability/specialization
• Widely applicable
• Modular/self-contained
• Complete and consistent
• Machine independent
• Implementation/application independent
• Data model independent
• Reliable
• Robust (good error/exception handling built in)
• Understandable/well documented
• Adaptable/extensible
• Standardized
• Portable (across hardware and operating systems)
• Certified/testable
• Maintainable
• Encapsulated (details are isolated and hidden from user)

McClure has also provided the software industry with techniques for building reusable components independent of whether or not an object-oriented language is available. This makes the technique applicable to GIS applications development in the entire line of Esri development languages, to include traditional proprietary languages, such as AML or Avenue, as well as the Open Development Environment languages, such as Visual Basic, C++, or TclTk. The techniques for creating components most applicable to reuse, as presented by McClure, are as follows:

1. Generalize
2. Standardize
3. Automate
4. Certify
5. Document

The following sections address each of these well-known techniques in the software engineering industry. The techniques are mandatory in the component production process to avoid retrofitting activity for the next developer who attempts to use the component. It is recommended that GIS application developers follow these guidelines to the extent that time and budget allow, regardless if the component being produced is specifically designed and designated a "reusable component" or not. A GIS application will be reused whether or not it was originally intended to be reused. By following these guidelines, applications will be much more "ready" for or have a greater potential for future conversion into a generic reusable component.

• Use parameters or parameter lists for invoking the component. The specializations will provide unique parameter values to determine or cause different behaviors.
• Remove internal/implementation details/dependencies. For example, the same component could be built in two different languages. The use, function signature, behavior, etc., may be exactly the same for both implementations, but the internal implementation of the component may be entirely different depending on the language used.
• Separate the behavior of the component from the application-specific use, business rules, logic, and procedures.
• Represent the component at a higher level of abstraction. Develop a clear description of the component without using application-specific details.
• Practice information hiding and encapsulation.
• Describe components by requirements that are the same regardless of the use or application and describe them by requirements that will differ from application to application.
• Design two parts to each component: (1) the fixed part, and (2) the variable part. A reuser of the component should only need to change the variable part. The more implementation that can be placed in the fixed part, the more reusable the component becomes.

• Invoking, controlling, and terminating function.
• Error handling.
• Help subsystems and routines.
• User interface.
• Documentation and appropriate comments.
• Compliance with standards (e.g., design specifications, OLE, CORBA).
• Naming conventions.
• Cursor and query processing.
• Standardized interface for both data and methods of component.
• Single entry/single exit, if applicable.
• Avoid literal constants, excessive levels of inheritance, and excessive use of complex logical constructs.
• Maximize cohesion; all operations in a component are closely related.
• Minimize coupling; reduce connectivity and dependencies on other components (e.g., avoid use of global variables).
• Performance of component in tests for adherence to design and reliability conducted by a separate individual or entity.
• Proper use of information hiding - If developed correctly, another developer should not need to know what happens inside the component. For example, inputs, outputs, the behavior of the component, and results are all the next software engineer should ever need to know about the component in a reuse scenario.

• Testing
• Inspection
• Complexity Measurement
• Automated syntax check
• Standards compliance
• Performs according to design and documentation
• Component has no external data dependencies
• Platform portability (e.g., test an AML component on both NT and UNIX platforms)
• Is the component actually used in multiple systems
• Reuse statistics
• Internal code review/walk-through
• Unit, as well as integration, testing has been performed

• Name of the component
• Classification/categorization of the component
• Interface requirements
• Description of what the component does
• Description of the components properties
• Reuse specific information (e.g., history of reuse, limitations and conditions for use, how it should be used, systems it is implemented in)
• Specification of the component
• Quality/certification
• Author and creation data
• Tests developed for the component (e.g., test plan, use cases, data, results)
• Who maintains the component
• Recommendations for improvements
• Links to requirement specifications
• Version and language implementation data
• Relationships to other components

Listed below are several practical guidelines and advice to assist developers in the creation of new reusable components:

• Collaborate with multiple software engineers throughout the design and definition phases.
• Install a reuse analysis stage into all detailed design work, so that the opportunities for reuse can be effectively assessed.
• Before building a new component, always check to make sure it does not exist. Always attempt reuse before creating a new component.

• Strive for a clearly defined, single purpose per component.
• Document all component interface requirements, also known as parameter lists or function signatures, in the design phase. Do not attempt to start at the coding phase and "design as you go." Remember that component reuse requires much more up-front planning. More design time and less construction time should be expected and planned for by project managers.
• With the inputs, results, or outputs and a description of a component, another software developer should be able to use that component without ever knowing what the code does inside the component. The component should pass this "self test."
• Strive for loosely coupled and highly cohesive components.
• Develop components with overall future use in mind, not just a single project.
• Always put extra effort into error handling and making components robust.
• Develop a certification program and communicate the certification criteria to all component developers.
• Use consistent design styles.
• Implement and use naming conventions.
• When creating documentation, think of explaining the component to a developer unfamiliar with the internal workings or a developer who will truly never look at the code of the component.
• Thoroughly test the component.

 Component Repositories

A reuse library or component repository organizes, stores, and manages reusable components, often supporting multiple versions of the components (McClure 97). The primary requirement is assigning and dedicating a staff resource to tend to and manage the repository. A secondary requirement is allowance for developer access to the library in a manner that makes searching for and finding components an easy task. McClure recommends that several tasks be performed in the creation of a repository, including most of the following:

• Define the types of components for storage in the repository.
• Define the organization structure for the reuse repository.
• Select a good configuration management tool [e.g., Clear Case (excellent commercial system) or Concurrent Versioning System (excellent shareware)].
• Implement as much automation as the market will provide, such as cataloging tools and repository browsers. (This is one area of software engineering tools that is somewhat limited now, but will experience explosive growth this year).
• Define a classification scheme for indexing each component. The scheme should allow for change and growth over time. Examples of indexing fields and a list of contents or values that might be used for each are as follows:

• NAME: (unique name of component)
• TYPE: (application, architecture, plan, utility function, screen layout, report, menu, data model, data structure, entity type, process/function, procedure/algorithm, model, testing tool, documentation)
• APPLICATION AREA: (Utilities, N/A, Planning, Assessment, etc.)
• MEDIUM: (code, design, application, prototype, template, text, skeleton, test, documentation)
• TECHNOLOGY: (language/architecture, such as AML, Avenue, or VB; data modeling language; object-oriented technique, such as OMT, Booch, or Yourdon-Coad; CASE tool; word processor; class library)

• Classification, cataloging, and certification needs to be performed for every component placed into the repository.
• A defined growth path and plan should be adopted for needed components. As more and more application development is performed on a given architecture, the projects should be burdened with populating the repository where and when needed.
• A corporate repository should be treated as any other valuable asset in the corporation. It will need to be managed, budgeted for, and upgraded, and its status and contents need to be communicated often to users of the asset.
• Implement a repository browser and search engine. Development and implementation of Web-based tools may be the best approach for browsing and searching.

• Consider size of organization.
• Consider investment required.
• Acquire tools required to support the transition.
• Plan, implement, and analyze incremental efforts to adopt reuse.
• Implement a reuse incentive system. Incentives may take the form of monetary rewards or recognition and reward programs. The incentive should draw positive attention to reuse and promote its implementation.

• Develop reuse metrics to determine where you are in implementing your plan and to give yourself a way to determine when changes are required to your strategy.

• Treat technology transition as a project: manage it, resource it, schedule it, and measure progress.
• Select and conduct a small pilot reuse project.
• Implementation of change.
• Set expectations, conduct training, and keep everyone up to date on what goes into a reuse repository.
• Communicate the results of your initiatives to your internal development and management teams, as well as to your clients or customers, letting them know how you are improving the value of your products.

 Implementing and following reuse practices does not come without a price tag. Sometimes substantially more effort is required to build for reuse. For example, to create a generic reusable form of a program module can take twice as long as creating it for one time use...and to create a general object class may require 10 times the effort to create the class for use in one application (Jacobson 92). Additional design and planning efforts will be required initially.

• Rapidly changing underlying technology
• Expectation of an early high payoff
• Not selecting a narrow domain as a starting point
• Focusing on developing components for deliverables of a single project, instead of multiple projects

• Inadequate configuration and version management control mechanisms
• Inadequate searching/browsing/look-up mechanisms
• Too little control over what is put in a library
• Undocumented interfaces and/or components
• No facility for exceptions; all or nothing reuse
• All requirements cannot be satisfied all of the time
• Neither top-down nor bottom-up design is adequate to capture the benefits of reuse
• Lack of support tools

Rod D. Kuhns

Senior Software Engineer

Convergent Group

6200 S. Syracuse Way, Suite 200

Englewood, Colorado 80111

(303) 741-8400

http://www.convergentgroup.com

Email: Rod.Kuhns@cvg-grp.com