by Gillian Kendrick and Peter Batty
Abstract
The implementation of large corporate GIS systems places heavy demands on the customisability of GIS products. This paper examines the use of an integrated CASE tool in GIS customisation. The authors start by discussing some of the common problems which designers of GIS systems face in developing new applications. The paper describes the or features which a CASE tool should include in order to address these issues. The similarities between the technology which can be used to underpin both a CASE tool and a GIS will be mentioned.
The paper describes the practical use of a CASE tool in application development. It also discusses the management of multi-user application development and the benefits gained from utilising a CASE tool in the development process. It is shown that the use of an integrated tool facilitates the adoption of a new incremental design methodology.
Introduction
One of the greatest costs in large GIS implementations is that of customising the basic system to meet an organisation's specific requirements. There are many aspects to this customisation. The user interface of the system may be tuned to speed up data capture or else to streamline the execution of particular queries. The way in which object's spatial attributes are displayed must be specified. However, one of the most significant parts of any customisation involves the design and maintenance of the application's data model.
Data modelling is a complex task for most computer applications, but this is particularly true in GIS for several reasons. The first of these is the large number of classes of objects which are involved in these systems. Each implementation will typically involve hundreds of different object classes. The second factor is the number and variety of relationships between these objects. Relationships are of three main types: aggregation and association, e.g. a building is 'part of' a school; spatial, e.g. a house is 'near to' a lake; and topological, e.g. a valve is 'connected to' a pipe. Of these types, only the first may be explicitly represented in terms of traditional relational joins. The others will be derived indirectly from spatial attributes of the objects or else through the interaction between these spatial attributes.
For many organisations, the GIS will only form a part of the corporate computing system. There will be existing data bases holding data such as customer information. Some of this data may be relevant to the GIS, and therefore part of the customisation will involve integrating these existing data models with that of the GIS (Bundock & Theriault 1992). This integration will again increase the size and complexity of the overall design.
Another aspect of GIS implementations, which has an impact on the maintenance of the data model, is that user requirements change. GIS projects typically have quite long life cycles, and the technology is relatively new to most users. This means that at the outset of the project they may not realise the full capabilities of the system. As new applications are developed and added to the system, changes are required in the data model.
Since GIS projects involve capturing large amounts of data, it is critical that these changes to the data model can be made without losing or compromising any data which is already stored in the system.
With most traditional GIS software, data model evolution is a difficult issue. This has meant that a long period of time has been spent at the beginning of the project on requirements analysis and data model design to try to make sure that it is exactly right, which of course is rarely achieved. This has had to happen before any other work could begin, meaning that there has been a very long delay for users between the purchasing of a GIS and the start of productive use of the customised system.
This paper describes how an integrated CASE tool can be used to address all of these data modelling issues. This in turn radically changes the way in which one can approach the problem of customising a GIS, using an interactive design methodology.
What is a CASE Tool?
The acronym CASE stands for Computer Aided Software Engineering. It is used to describe a variety of computer-based tools which can be used to assist in the design and development of computer programs. Such tools have been developed for various purposes including the analysis and documentation of procedures and data flows, and the design and documentation of a data model. It is the latter function which we consider in this paper as this is the most appropriate kind of tool to help with GIS customisation.
A CASE tool which is to be used for data model design must display a graphical representation of the model. This is usually in the form of an entity-relationship diagram which shows the entities, or classes of objects, and the relationships between them. Such a facility gives the designer a good picture of a large design. The tool allows plots of the diagram to be made. These can be included as part of the documentation of the overall design.
The tool allows the designer to interact with the spatial representations of object classes and relationships. A graphical user interface (GUI) provides an environment in which the attributes and behaviour of the objects and relationships can be edited and queried. The tool produces automatic documentation on selected parts of the design.
One of the ways in which a CASE tool can reduce the time taken to implement a design is by automatically generating the code which creates the data model. This facility has two main benefits. Firstly the designer no longer has to worry about implementation details; he can concentrate on the task of data modelling. Secondly, the automatic code generation speeds up the process of creating data mode]s, and avoids programming errors.
The tool should also provide facilities which enforce the correctness of the data model. It should validate that the design is consistent. Checks made by the tool at the design stage will reduce the amount of time spent in tracing bugs by the designers at a later date. This will again speed up the delivery of finished applications.
This section has described general requirements for a CASE tool which is to be used for data model design. The next two sections describe in more detail some of the requirements for CASE tools which are to be used in GIS. The first section covers general requirements for tools for GIS data model design. The second considers the extra requirements for an integrated tool and covers some of the benefits provided by such a tool.
CASE Tools for GIS
Multi-User Design
It was mentioned in the introduction that one of the reasons for the complexity of GIS data models was that they involved a large number of classes of objects. It will usually be the case that more than one designer will be involved in the development of these objects, their relationships and their behaviour. This means that it is important that the tool used to develop the data model is multi-user.
Each designer should be able to work on additions or modifications to the data model without being affected by changes which others are making to different parts of the design. These changes will also be made over a long time scale - maybe hours, days or weeks. The designer may wish to try out several alternative versions of the data model in order to settle on a best design. When a new part of the model has been completed or re-engineered, the tool must offer support for 'merging' the new work in with the rest of the design.
The requirements of CASE tool database technology in this area, involving long transactions and version management, are very similar to those of GIS. (Easterfield, et al. 1990).
Modelling of Spatial Data and Topological Relationships
GIS data models are special because they require the user to model spatial attributes of objects. New data types such as point, area, chain, raster and grid are supported. The tool also models the topological relationships which will exist between some objects. For example a valve location 'connects to' a pipe centreline, a land parcel 'shares' its boundary with another land parcel.
These aspects of GIS data models should be supported in a CASE tool which is to be used in GIS customisation.
Integrated CASE Tools for GIS
For high level conceptual design, it is not necessary to have a close coupling between the CASE tool and the DBMS used to implement the system. However, if the CASE tool is to be used for the physical database design and to generate code, then a much closer link is required between the tool, the DBMS, and the application development environment used to implement the actual system. The requirements for the tool if it is to achieve this higher level of integration can be separated into two parts.
First, the CASE tool must support all of the data modelling concepts supported by the GIS. These include things such as the datatypes, relationships and other system specific concepts such as triggers, validators, and enumerators. For object oriented systems, the CASE tool should also manage the behaviour for the object classes (Booch 1991). In particular for GIS the CASE tool needs to manage spatial information and topological relationships. The CASE tool may extend to covering aspects of the user interface of the application, such as which fields are visible to the user and what sort of interface is used to edit objects and their individual fields.
Second, the CASE tool must generate code in an appropriate format which implements the data model which has been designed. in the case of the work reported here, the tool produces a script in the language Smallworld Magik.
These requirements are to a certain extent independent of each other. If the first one is met, but not the second, then it is at least possible to use the CASE tool to do the logical design for the system, but the code to implement this then has to be written manually. on the other hand, it is possible to have a CASE tool which supports a subset of the concepts supported by the DBMS (with GIS, for example, a CASE tool which supports alphanumeric datatypes but not spatial datatypes). This could be made to output code in an appropriate format for the DBMS, but further development work would then be required in the DBMS environment (outside the CASE tool) to incorporate any of these additional concepts in the application. In this situation it is likely to be much more difficult to usefully maintain the data model using the CASE tool after its initial creation, since it does not know about any of the changes which have been made to the data model within the DBMS environment. Clearly, the CASE tool is much more useful if it meets both of these requirements in full.
A CASE tool which can generate the data model for a GIS application automatically is a very useful part of a development tool kit. There are two more facilities however which are necessary in order to make the tool truly useful for corporate GIS design.
Integration of Existing Data Models in the GIS Data Model
Something that was mentioned in the introduction to this paper is that a common requirement in GIS implementations is that existing (legacy) databases, and therefore data models, should be integrated into the system. It will often be the case that there are relationships between objects which have been created as part of the GIS and those which belong to these other databases.
As an example consider a large utility company that has a customer information database. It is undesirable to move this data to the GIS as many other applications will already be designed to run on it. Part of the requirement of the GIS application is to associate spatial information with those customer records.
To facilitate this integration, the CASE tool can 'reverse engineer' the data models from these existing databases. The objects can then be integrated into the whole design within the domain of one tool.
Maintenance of the data model
GIS applications involve large amounts of data, and as mentioned before, they are also particularly prone to having the user requirements change during the life cycle of the project. If a change in the user requirements means that the data model must be modified, then it is essential that facilities are provided to 'forward engineer' the populated database to be consistent with the new datamodel.
A common feature of CASE tools is that they generate the code which creates a design. It is less common to generate the code which will 'forward engineer' an existing design when the data model definition held in the tool has been changed. A CASE tool for GIS should offer support to evolve a database from one schema to another.
Features of an Integrated CASE Tool for GIS
Based on the previous sections, we can summarise that an integrated CASE tool should have the following features:
- Support all of the data modelling concepts which are supported by the GIS DBMS
- Generate the code which will implement the data model in the GIS DBMS 'reverse engineer' existing data models so that their schema can be integrated into the overall design for the system
- 'forward engineer' populated databases when the design of the objects and relationships is updated.
Such a tool provides significant benefits in the speed of GIS customisation and also in the maintenance of the applications throughout their life cycles.
Similarities Between a GIS Application and a CASE Tool
Several of the capabilities provided by a CASE tool are similar to those which are found in a GIS.
Firstly, in both systems, the user creates objects which combine both spatial and alpha-numeric attributes. In the GIS, these objects are things such as houses, pipes or rivers. The alpha-numeric attributes of a house are things such as its address and owner, and its spatial attributes are its position and footprint. In the CASE tool, the objects which the user works with are the definitions of the classes of objects which are to be used in the GIS application. For example, a CASE tool object has an alphanumeric attribute which holds the name of an object class, this could be 'House'. The spatial attributes of these objects are used to position them in the entity-relationship diagrams. Similarly, the CASE tool stores relationship objects, their attributes would include the type of the relationship, e.g. 'part of' or 'connected to'.
In both the CASE tool and the GIS, users can query and edit the properties of the objects through a GUI. This interface provides facilities for plotting and reporting.
One of the areas in which a GIS and CASE tool are most similar is in their need to provide support for multi-user working in a long transaction database. This should not be surprising as both systems are used as design tools as well as information systems.
The Smallworld CASE Tool
After a consideration of the benefits of using an integrated CASE tool, and a survey of the tools currently available on the market, Smallworld chose to implement its own. Because of the similarities outlined above between GIS and CASE, it was possible to implement the tool as a specific GIS application with its own data model.
Working with the CASE Tool
The tool is activated during a normal GIS session. The designer can have both the GIS application and the CASE tool running at the same time.
[Figure not yet available]
Figure 1. Integration of GIS and CASE in one environment
Application Development with the CASE Tool
Smallworld GIS contains a powerful data dictionary which supports many advanced data modelling features. These include the definition of new data types, triggers and validators. The data dictionary is capable of storing the definition of object classes, their attributes, behaviour and also the details of the topological and associative relationships between them. The data dictionary can manage many different versions of a data model and allows the designer to look at these different versions within one GIS session.
The CASE tool operates directly on the GIS application's data dictionary. If the GIS application involves integration with external databases, the data models held in these databases are reverse engineered into the tool. Once present in the tool, the user can add spatial attributes to the objects, and can also define relationships between them and the objects which live in the main GIS database. The user can also add behaviour to these external objects.
The CASE tool supports a steady progression from a logical to a physical definition of the required data model. It does not demand that the data model is completely defined but will advise on areas which are not yet complete. Facilities are provided which allow the designers to document the model extensively as they are working.
Developing the Data Model
As already mentioned, the CASE tool is a multi-user facility. We will now describe how many users can work on the same model.
[Figure not yet available]
Figure 2. Version management of both schema and GIS data
In figure 2, the boxes to the left of the dotted line represent the different alternatives in the CASE tool's database. Beneath the Top alternative there are two others where the designers Phil and Betty can work independently. The user Phil also has another two sub alternatives where he can try out different designs. The area to the right of the dotted line shows the alternative tree in the main GIS application. Beneath the Top, there are two alternatives Live Data and Test. The alternatives beneath the Live Data alternative are those where the GIS application is being used. The GIS applications may include data capture, analysis of existing data and design. The part of the tree under the 'Test' alternative is used by CASE designers to try out their developments. When Phil decides that he has completed a part of a design in the alternative 'Design 1', he can make the CASE tool 'apply' the new data model to the alternative 'Test 1'. At this point, he can immediately start testing the new data model in the GIS application. If after testing, the new part of the design is found to be a success, the changes he has made can be 'posted' up to the Top of the CASE database. If the design was unsatisfactory, he can proceed to improve it and then 'apply' the new changes.
When changes have been made to the design which have been thoroughly tested they can be applied to the Top alternative of the GIS application's database. That alternative will have its data model forward engineered'. Data model changes then spread through the alternative tree as users at lower alternatives request to see them.
[Figure not yet available]
Figure 3. Part of a GIS application's data model
The use of an integrated CASE tool in GIS allows designers to develop data models iteratively. There no longer needs to be such a great reliance on getting the design right first time. This in turn means that the end users can rapidly be presented with a prototype system which allows them to more easily understand what the system can offer. They are therefore able to offer much more feedback in the design of the system, leading to the development of systems which are much better suited to their requirements.
Data Model Re-use
Another feature of the CASE tool is that it facilitates the re-use of pieces of design. It can archive complete sections of data model in a format which can be read in by another tool. This has enabled the setting up of a library of designs. This greatly speeds up the development of new applications as they rarely have to be designed from scratch. An existing 'template' data model can be loaded in to an applications CASE tool and this can be thought of as the first prototype.
Conclusions
Since Smallworld commenced using an integrated CASE tool for application development the following benefits from this approach have been found:
- Customisation of the system has been made more accessible. The tool has reduced the size of the knowledge barrier which designers have to overcome, as they no longer have to be trained in how to talk to the underlying DBMS directly. They can instead spend more of their time with design considerations. This means that more people are able to customise the system with less initial training
- The tool has enabled the creation of applications which better meet the customer's requirements through the interactive development approach. Users are given the chance to interact with a version of the application at an early stage. They can then refine their requirements, the developers can evolve the design and the tool will evolve the database.
- Designs are more easily re-used. The archiving facility in the Case tool allows parts of designs to be stored in a form where they can be loaded in to another tool. This means that a library of commonly used parts of designs can be set up. When a new application is being developed, much of the initial data model can be created from these standard components. This has two main benefits: firstly the development time for new applications is greatly reduced; secondly, the quality of developed applications is improved. Time invested in improving the quality of the basic data model components leads to improvements in the overall system quality.
- Multi-user working is easier to manage. It is always a difficult problem when many designers are working on the same project to avoid duplication of effort, and conflicts between their different designs. The CASE tool aids in these problems by incorporating a number of validation and completeness checks which will prevent the design from becoming inconsistent. The users can develop parts of the data model independently in separate alternatives. When they incorporate these into the total design by merging' their changes, the DBMS automatically spots any conflicts in the design which the designer has introduced and allows him/her to reconcile them.
- An Incremental development methodology means that designers can get production systems in place much more quickly.
References
Booch, G. (1991) Object Oriented Design with Applications. Benjamin/Cummings, Redwood City California, 1991
Bundock, M. & Theriault, D. (1992): Integration Of Case Technology into the GIS Environment, in AGI92 Conference Papers, Birmingham, November 1992
Easterfield, M., Newell, D.G. & Theriault, D. (1990): Version Management in GIS - Applications and Techniques, EGIS 90 Conference Proceedings, Amsterdam, April 1990.
Posts
No comments:
Post a Comment