ArticlePDF Available

Abstract

The problem of building and maintaining large and heterogeneous information systems -- not only spatial ones -- is a problem generally acknowledged by the software industry [1]. Software engineering provides different techniques and tools for structuring the software development process into different phases. Thereby, one of the most important phases (and products) is the specification [2, 3]. It structures a task at hand into single actions, describes the restrictions of the actions, and captures which results are expected. However, the specification does not go into detail about how the actions are executed. Specifications are the core of standardization efforts since a specification defines the underlying conceptual model of a standard (i.e. the "world" and its meaning). Standards go one step further, and specify implementation interfaces for tasks (i.e. data structures and operation signatures) to achieve interoperability between information systems. For standards, it is signifi...
Formalisation of Spatial Standards
Silvia Nittel
Data Mining Lab, Computer Science Dept.
University of California, Los Angeles
silvia@cs.ucla.edu
Stephan Winter
Department of Geoinformation
Technical University Vienna
winter@geoinfo.tuwien.ac.at
Extended Abstract
The problem of building and maintaining large and heterogeneous informa-
tion systems not only spatial ones is a problem generally acknowl-
edged by the software industry [1]. Software engineering provides different
1
techniques and tools for structuring the software development process into
different phases. Thereby, one of the most important phases (and products)
is the specification [2, 3]. It structures a task at hand into single actions,
describes the restrictions of the actions, and captures which results are ex-
pected. However, the specification does not go into detail about how the
actions are executed.
Specifications are the core of standardization efforts since a specification
defines the underlying conceptual model of a standard (i.e. the ”world” and
its meaning). Standards go one step further, and specify implementation
interfaces for tasks (i.e. data structures and operation signatures) to achieve
interoperability between information systems. For standards, it is significant
that the semantic aspects of implementation interfaces are unambiguous so
that all people who build products upon the standard have the same under-
standing about the meaning of interfaces. This is complicated by the fact
that:
specifying experts and implementation experts often cannot communi-
cate directly when standards are published;
therefore, full understanding of the specification has to be derivable
from the specification documentation directly;
2
specifications with a status of a standard should be consistent and
error-free to avoid costly changes to products.
Current specification techniques in spatial standard organizations are
based on graphical object oriented modelling in UML [4, 5]; they lack for-
mal modeling of the semantics of interfaces. The requirements in the field
of spatial information systems recently lead to proposals to use algebraic
specifications as an appropriate tool [6, 7, 8, 9, 10]. Algebraic specifications
have mathematical clean form, and allow to capture the semantics of opera-
tions formally [11, 12, 13]. Furthermore, they are constructive, which means
they are executable and their behavior can be checked when implemented
using functional programming languages, and modules can be composed to
more complex systems. Today, languages like Haskell are suitable tools to
implement multi-sorted algebras since they are declarative, operational, and
object-oriented [14]. The work of Kuhn and Frank demonstrates the usability
of Haskell for capturing the semantic of expressions.
In this paper, we go one step further, and investigate the applicability, and
usefulness of multi-sorted algebras and functional programming languages as
a specification tool for spatial interoperability standards. To test our case,
we choose the coverage section of the OpenGIS Consortiums’s (OGC) spatial
3
interoperability standard, and modeled and implemented the specification
of OGC coverages via Haskell. In contrast to the semi-formal UML tool
chosen by OGC we were able to capture operation semantics in a formal,
and less unambiguous way, and test the correctness and consistency of the
specification via executable code. Certainly, a formal specification does not
come without a price. The syntax of functional programming languages
seems to be less intuitive to use and understand in the beginning, and is
a unfamiliar tool for many people involved in the standardization process.
In this paper, we discuss and evaluate the effectiveness of such a tool for
the definition of spatial standards, and discuss its applicability to the real-
world process of standardization. We came to the result that a functional
specification would be a useful and necessary replacement and/or supplement
to the verbal and semi-formal specification methods used today.
References
[1] W. W. Gibbs, “Software’s chronic crisis”, Scientific American, vol. 271,
no. 3, pp. 72–81, 1994.
[2] B. Liskov and S. Zilles, “An introduction to formal specifications of data
4
abstractions”, in Current Trends in Programming Methodology (R. T.
Yeh, ed.), vol. 1, pp. 1–33, Englewood Cliffs, N.J.: Prentice-Hall, 1978.
[3] B. Liskov and J. Guttag, Abstraction and Specification in Program De-
velopment. The MIT Electrical Engineering and Computer Science Se-
ries, Cambridge, MA: MIT Press, 1986.
[4] OMG, “UML resource page”, http://www.omg.org/uml/, 2000.
[5] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Lan-
guage Reference Manual. Reading: Addison-Wesley, 1999.
[6] M. J. Egenhofer and A. U. Frank, “Object oriented modeling for GIS”,
Journal of the Urban and Regional Information Systems URISA, vol. 4,
no. 2, pp. 3–19, 1992.
[7] A. U. Frank and W. Kuhn, “Specifying open GIS with functional lan-
guages”, in Advances in Spatial Databases (M. J. Egenhofer and J. R.
Herring, eds.), vol. 951 of Lecture Notes in Computer Science, (Berlin),
pp. 184–195, Springer, 1995.
[8] A. U. Frank and W. Kuhn, “A specification language for interoperable
GIS”, in Interoperating Geographic Information Systems (M. F. Good-
5
child, M. Egenhofer, R. Fegeas, and C. Kottman, eds.), pp. 123–132,
Norwell, MA: Kluwer, 1999.
[9] W. Kuhn, “Approaching the issue of information loss in geographic data
transfers”, Geographical Systems, vol. 4, no. 3, pp. 261–276, 1997.
[10] A. U. Frank, “One step up the abstraction ladder: Combining algebras
from functional pieces to a whole”, in Spatial Information Theory
(C. Freksa and D. M. Mark eds.), vol. 1661 of Lecture Notes in Computer
Science, Berlin: Springer-Verlag, pp. 95-107, 1999.
[11] J. V. Guttag and J. J. Horning, “The algebraic specification of abstract
data types”, Acta Informatica, vol. 10, pp. 27–52, 1978.
[12] I. V. Horebeek and J. Lewi, Algebraic Specifications in Software Engi-
neering. Berlin: Springer-Verlag, 1989.
[13] J. Loeckx, H.-D. Ehrich, and M. Wolf, Specification of Abstract Data
Types. Chichester: Wiley-Teubner, 1996.
[14] P. Hudak, J. Peterson, and J. H. Fasel, “A gentle introduction to Haskell
98”, http://www.haskell.org/tutorial/, 1999.
6
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
Denver's new international air port was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag. At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its 193millionsystem.DecemberyieldedtoMarch.MarchslippedtoMay.InJunetheairportsplanners,theirbondratingdemotedtojunkandtheirbudgethemorrhagingredinkattherateof193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging red ink at the rate of 1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open. To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all. Photo of Dallas International Baggage Handling System: SOFTWARE GLITCHES in an automated baggage-handling system force Denver International Airport to sit empty nine months after airplanes were to fill these gates and runways (top). The system that is supposed to shunt luggage in 4,000 independent "telecars" along 21 miles of track still opened, damaged and misrouted cargo as testing continued in July (bottom). The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as the software crisis. Although the experts could not contrive a road map to guide the industry toward firmer ground, they did coin a name for that distant goal: software engineering, now defined formally as "the
Article
Full-text available
Geographic data are now being transferred on a daily basis within and between organizations worldwide. The low-level technical problems of data transmissions are largely solved and significant progress on transfer formats is being made by standardization bodies. However, an issue that had long been considered minor is turning into a can of worms: the problem of transferring geographic information, i.e., the meaning of the data and not just the data themselves. This paper proposes to approach this problem algebraically, in three steps: (1) to formalize data models as algebras, describing data and operations together; (2) to describe mappings between models as morphisms, formalizing the transfer functions; and (3) to model invariant properties as homomorphisms, identifying everything else as information loss. An outline of this approach is presented, applied to a detailed example, and discussed with respect to its practicality. © 1997 OPA (Overseas Publishers Association) Amsterdam B.V. Published in The Netherlands under license by Gordon and Breach Science Publishers.
Chapter
Specifications of software interfaces are essential for interoperability. If an interface is not clearly specified, software that exposes or uses the interface necessarily contains assumptions that can make it non-interoperable with other software based on different assumptions. Eliminating, or at least coordinating such assumptions requires a precise and complete specification language. If such a language also allows for prototyping of the specified components, it is a much more powerful tool in the specification process and can even support conformance testing. This chapter describes why and how functional languages serve all these purposes.
Article
There have been many recent proposals for embedding abstract data types in programming languages. In order to reason about programs using abstract data types, it is desirable to specify their properties at an abstract level, independent of any particular implementation. This paper presents an algebraic technique for such specifications, develops some of the formal properties of the technique, and shows that these provide useful guidelines for the construction of adequate specifications.