Requirement Analysis for the Definition of Reusable Spatial Objects

GeoInformatica 3:4, 305±335 (1999)

# 1999 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

Requirement Analysis for the De®nition of ReusableSpatial Objects

FLAVIO BONFATTI, AND ROBERTO MONTANARI1Department of Engineering Sciences, University of Modena and Reggio Emilia, via Campi 213/B, 41100Modena (Italy)E-mail: (bonfatti, robertom)@unimo.it

PAOLA DANIELA MONARI

SATA srl, via Notari 103, 41100 Modena (Italy)E-mail: [email protected]

Abstract

Requirement analysis plays a critical role in designing geographical information systems because it aims to

capture user informational needs correctly and fully. Proposed analysis and design methodologies either adapt

general-purpose approaches to this application ®eld or extend them by introducing speci®c constructs to better

capture the spatial properties of objects. Many of them are based on the object-oriented paradigm; unfortunately,

they usually lack expressive power so that a wide gap remains between the contents of the resulting

documentation and the required depth of the detailed application design. The solution we propose is based on the

GeoMDT model, which combines the modeling capability of current conceptual data models with that of

predicate calculus formulas under a uni®ed paradigm in order to express object dynamics in form of invariant.

The strong points of the GeoMDT model are independence of the GIS technology, easy identi®cation of routine

functions, effective guide to modular design, and a high reuse potential obtained through the nested encapsulation

mechanism.

Keywords: requirement analysis, design, modularity, reuse, object-oriented model, spatial properties, object

dynamics

1. Introduction

The fundamental role played by requirement analysis in the construction of information

systems of any type is widely recognized [2], [15], [18]. The outcome of this phase is

highly critical due to the impact it has on the capability for fully capturing the user

informational needs. Furthermore, the system life cycle, as well as the reuse potential of

software and data structures, relies on correctness and completeness of the collected

requirements. This in¯uence is particularly evident in the case of geographic information

systems, which manage large amounts of data, support the activities of a wide variety of

users, and are subject to periodic revisions and extensions.

The ®rst and most important GIS technology development occurred in the 1980s,

accompanied by the diffusion of regional geographic information systems to support

public administrations and bodies involved in territory planning and environment control.

In that period, great emphasis was placed on how to manage burdensome numeric coding

of the huge amount of knowledge available in form of paper maps. This problem, together

with the simultaneous development of the relational culture and technology, prompted

researchers to focus on data organization and database design techniques rather than on a

more general system-oriented approach. This policy has many limitations, of which the

following are some of the most serious:

* Application needs are not taken adequately into account. Data are collected and coded

without an actual preliminary analysis of their effective usefulness and exploitation

potential.* The absence of a standard spatial data model results in as many design methods as

there are GIS technologies on the market. Design results are consequently transferred

very little from one system to another.* Insuf®cient effort is concentrated on making data meanings and correctness

constraints explicit. This knowledge remains hidden in the system procedures for

data testing and processing.* Spatial properties of territory entities are poorly represented, as they are usually

expressed in terms of the prede®ned, limited set of data types and topological relations

made available by the single GIS technology.* The cost of system management and use increases proportionally with the number of

applications, since no systematic attempt to achieve modularity and reuse is actually

made.

New methodologies for requirement analysis and design have been proposed in recent

years, along with those traditionally based on extended Entity/Relationship models, in

order to improve the early phases of the development cycle of geographic information

systems. Signi®cant examples are the application of object-oriented models [12], [23],

[32], [33] and the introduction of software engineering techniques [18], [19], [27], [28].

However, a major problem remains unsolved: only some knowledge aspects are actually

captured during the analysis and overall design phase. This means that a wide gap remains

between the contents of the resulting documentation and the required depth of the detailed

application design.

This suggests that both requirement speci®cation methods and detailed design

methods yield results that seldom have a signi®cant reuse potential. Requirements are

technology independent, but too poor to represent an amount of knowledge that is worth

reusing; on the other hand, detailed design outcomes are affected by implementation

issues and the chosen GIS technology, and are hence ported very little to other

applications or environments. What is needed is a requirement analysis and design

approach that constitutes a trade-off between these two situations: it should be able to

capture and formalize most of the application domain knowledge in a form that is

independent of the development environment. Moreover, it should favor the breakdown

of the application into a modular schema whose components are easily identi®ed and

potentially reusable.

Reusability requires that the de®ned modules be characterized by high internal cohesion

306 BONFATTI, MONARI, AND MONTANARI

and weak mutual coupling [22]. Functional cohesion and data-oriented cohesion are

de®nitely preferable, and a good analysis and design approach should produce modules of

either type. Functional cohesion is obtained in software routines whose aim is to compute

and return a result starting from given input data. It is high because it does not make sense

to further split it into components. Data-oriented cohesion is obtained when the module

collects operations all acting on a given data set. This realizes the object-oriented

mechanism called encapsulation.

Weak coupling is, in turn, achieved by ensuring that every module exchanges data and

calls with a limited number of other modules, and that these relations are explicitly based

on a sound design criterion.

Note that while the classical object-oriented approach is quite effective with respect to

module cohesion, it does not provide clear guidelines for disciplined module coupling.

Much research is currently focusing on overcoming this problem [16], [29] but it has not yet

impacted the ®eld of geographic information systems. This is the ultimate aim of our work.

The solution we propose is based on the GeoMDT model, originating from the results of

the Italian National Research Council's MULTIDATA project. The model combines the

modeling capability of current conceptual data models with that of predicate calculus

formulas under a uni®ed paradigm in order to express object dynamics in form of invariant.

More precisely, it adopts the basic principles of the object-oriented paradigm, but introduces

speci®c primitives to explicitly and fully represent value domains, relations and constraints.

The paper is organized into ®ve main sections. Section 2 relates our work to other

research in the ®eld of spatial knowledge representation. Section 3 introduces the

GeoMDT model concepts and primitives, Section 4 presents the model syntax, and Section

5 treats model application in greater depth by indicating modeling criteria with the aid of

examples. Finally, Section 6 analyzes the strong points of the GeoMDT model, namely

independence of the GIS technology, easy identi®cation of routine functions, effective

guide to modular design, and a high reuse potential obtained through the nested

encapsulation mechanism.

2. Related work

Several attempts to apply object-oriented methodologies to analysis and design of

geographic information systems have been made over the past ten years. In some cases

methods and tools developed for traditional applications have simply been transferred to

this ®eld, whereas in other cases they have been adapted with the introduction of speci®c

constructs to better capture the spatial properties of objects.

Experiences of the former type are reported in [12], [23], [27]. In the ®rst of these

papers, the authors discuss the suitability of object-oriented databases to store spatial

data, and describe the development of an application based on the ONTOS object-

oriented DBMS and its advantages over traditional solutions. The second paper proposes

a CASE tool for geographic applications, OOgeomorph, speci®cally conceived for

object-oriented spatial modeling of geomorphology. The third paper presents UAPE', a

tool for modeling and designing environmental geographic applications based on a

REQUIREMENT ANALYSIS 307

library of spatial object classes; these classes are used by the designer to de®ne new

entities according to the GMOD model. The core idea behind these and similar projects

is to build a framework of classes that introduce the fundamental, generic spatial

concepts. Other application-speci®c concepts can be derived from these through the

specialization mechanism.

A signi®cant enrichment example of a general-purpose model is Geo-OOA, proposed

by Kosters, Pagel and Six in [18], [19] as an extension to Coad-Yourdon's OOA model [8].

It introduces four speci®c geoclass types to manage the GIS related concepts (Point, Line,

Region and Raster), three topologic whole-part primitives and a network structure

primitive. This solution certainly increases the expressive power of the OOA model as

regards its ability to represent spatial properties, but it does not provide new ways of

describing object dynamics. Our approach differs in two aspects. Firstly, we consider it

critical to formalize constraints and behaviors as early as at the analysis and design stage.

Secondly, we prefer to provide general primitives for tailoring spatial structures and

relations to application needs rather than a ®nite set of pre-de®ned concepts.

Another paper presents the GRDM formal model to support the logical design of

geographic databases [17]. It constitutes an extension of the relational model with

constructs to de®ne relations, layers, objects and constraints, and focuses exclusively on

spatial and topological aspects. By contrast, our viewpoint is more general and aims to

achieve a homogeneous representation of spatial and non-spatial objects and their

properties (e.g., layers and buildings are modeled with the same GeoMDT primitive).

As regards conceptual modeling of spatial databases, an important aspect is to provide

constructs to express both object positions and space-varying attributes. Many papers, [10]

and [6] amongst others, discuss the dichotomy between object view and ®eld view. We

agree with Tryfona [30] that both aspects can be captured within the same geographic data

modeling paradigm. However, we have chosen to achieve this using a new, specially

conceived model that supports both database and software design, rather then adding the

constructs of spatial aggregation and grouping to known semantic models.

We have already pointed out the importance of modeling constraints and dynamics in

addition to the static aspects of the application. An extensive analysis of spatial data

integrity constraints is reported in [9] together with a taxonomy of constraints and rules

and a discussion of how they can be implemented at the development stage.

The use of object-oriented active databases to maintain constraints, in particular

topological constraints, is presented in [21]. Constraints are transformed into rules, namely

(E, C, A) rules involving event (insert, modify, update) determination, and relations are

checked against the geometric components of geo-objects involved in constraints. We

express the constraints on object and relation states and state transitions as laws. Since

GeoMDT is a design language not related to a speci®c database technology, we leave the

developer the task of translating laws into triggering conditions and operations.

An extensive literature is devoted to de®ning spatial relations, implementing them in

spatial models and accessing them by spatial query languages [7], [13], [14], [25]. The

current GIS technology is based on conventional data models that do not encapsulate

spatial semantics effectively, and different GIS users (such as decision-makers) may adopt

their own models of space. It is dif®cult to express the wealth of such knowledge using


pre-de®ned primitives, which are necessarily based on a particular interpretation of spatial

relations. The GeoMDT model prefers to provide the designer with the general-purpose

``value'' and ``virtual'' primitives in order to allow every kind of spatial concept and

relation between spatial concepts to be de®ned.

Finally, within the software engineering community, many methodologies have been

proposed to achieve higher degrees of reuse, by recalling the concepts of modularity and

weak coupling [22], patterns, and framework [16], [29], as well as the design-for-reuse and

design-with-reuse keywords [26]. GeoMDT adopts a nested encapsulation mechanism to

increase modularity and reduce object interdependency, and provides the ``virtual''

primitive to extract all the regularities observed in object relations.

3. The GeoMDT model

The GeoMDT model is object-oriented in that it organizes the information into objects, each

characterized by its own data structure and behavior. Like most object-oriented models,

GeoMDT expresses object properties as attributes. The state of every object is given by its

attribute values; objects sharing the same attribute set and behavior are considered to be of

the same type, and constitute the instances of the object class of that type.

GeoMDT differs from the classical object-oriented paradigm principally in that it

replaces methods with laws expressing constraints on object states and state variations.

Other differences concern the distinction of objects into three different categories

according to their semantics, and the adoption of a disciplined modeling method that

ensures object independence and visibility.

3.1. Primitives

The objects de®ned by GeoMDT belong to three semantic categories represented by three

modeling primitives: value, object and context. GeoMDT also provides a fourth primitive,

virtual, for capturing regularities in the interaction between values or objects.

* Object. Objects model the entities of interest that populate the application domain

under study. We perceive entities through their observable properties, including spatial

properties. Entities are modeled by the object primitive, while their signi®cant

properties are quanti®ed as object attributes.* Value. An object attribute is a function that maps onto a value domain. The domain

includes either elementary values (e.g., Integer) or complex values (e.g., Region).

Values of increasing complexity are de®ned from simpler values through the tuple

construction mechanism [20]. Value is the primitive for expressing these de®nitions.* Context. Territory objects do not exist alone, but participate in situations together with

other objects. In general, two or more objects are related if their states change

contextually or are mutually dependent. The context primitive models the relations

between objects.* Virtual. Two or more objects can participate in a number of contexts (and, similarly,


two or more values can be found in the data structures of a number of objects). In order

to avoid redundant de®nitions, regularities in the interactions of such objects (values)

can be isolated and expressed once for all by the virtual primitive.

The semantic difference between value and object basically arises from the fact that the

former is not meaningful per se but as de®nition domain of object properties. In other

words, values are only instantiated within the states of the objects they contribute to

modeling. From an ontological viewpoint [5], [31], every object is unique and hence

distinct from any other even if they present the same state. Instead, values have no identity,

that is, their identities coincide with their states. This difference makes the distinction

between values and objects quite easy to understand and apply by the application designer.

This is the reason why it is adopted in other models, in particular the well-known O2 data

model [20]; also, in spatial modeling, the paper [6] introduces the concept of weak object

to represent pure locations.

On the other hand, the object and context concepts differ in that the latter is speci®cally

devoted to representing links between objects. Semantically, whereas an object has its own

identity, a context receives its identity from the objects it relates. If one of them is replaced,

the previous context instance ends and a new instance is observed. This distinction is lost

in widely used object-oriented programming languages, while requirement analysis and

design models, such as OMT [28], continue to use the association primitive as it is very

convenient to relate the objects of the application domain. Unlike other design models, the

GeoMDT context does not simply indicate the objects involved in real world situations,

but allows their mutual in¯uence to be detailed.

3.2. Composition and specialization

The GeoMDT model considers two basic mechanisms to express the relations between

concepts: composition and specialization.

Composition is the relation observed whenever one concept participates in the de®nition

of a more complex concept. The link between the component concept and the compound

concept is modeled by considering the former as an attribute of the latter. According to the

adopted semantic hierarchy of concepts, the following cases occur:

* Value in value. Complex values are obtained from simpler ones. For instance, the Line

value includes as attributes a list of Point values and a Real value expressing its length.* Value in object. The signi®cant properties of an object are modeled as attributes

mapping onto properly de®ned value domains. For instance, the attributes of Well are

its position and depth, expressed respectively by a Point value and a Real value.* Value in context. Contexts relate objects and detail their mutual in¯uence. For this

purpose, they often have attributes mapping onto value domains. For instance, a

hypothetical WellBuilding context, relating pairs of wells and buildings, could have a

Real attribute representing the distance.* Object in object. Objects can participate in the construction of other objects of higher


complexity. For instance, a River is made of a set of RiverBranch objects. This case is

modeled by giving River an attribute that maps onto the RiverBranch object class.* Object in context. The objects participating in a context are modeled as context

attributes. For instance, the cited WellBuilding context has two attributes that map

respectively onto the Well and the Building object classes.* Context in context. Albeit infrequently, a context may participate in another context

where it appears as an attribute. For instance, the WellBuilding context could be

associated with the Registrar object by the RegistrarOfWB context to indicate that the

registration varies according to the combined properties of the pair hwell, buildingi.* Values and objects in virtual. As speci®ed in the following, virtual objects relate

groups of values or objects in order to capture regularities in their interaction. These

regularities are expressed by attributes that in turn map onto value domains.

The specialization relation is the object-oriented mechanism for deriving a detailed

concept from a more generic one (ancestor). In the GeoMDT model, specialization applies

to all the three object categories:

* Specialized value. As the value primitive de®nes a value domain, value specialization

restricts an elementary or previously de®ned value domain. For instance, ClosedLine

is the specialization of Line with end points coinciding. Proper use of the

specialization mechanism leads to the de®nition of tailored domains suitable for

accurately characterizing the attributes that map onto them.* Specialized object. Object specialization restricts the object type (subtyping) and

consequently the set of instances of that type. In general, a specialized object presents

speci®c properties and/or constrained behavior with respect to its ancestor. For

instance, ActiveWell could be the specialization of Well providing water for human or

agricultural use.* Specialized context. Specializing a context means focusing on a particular case of the

modeled situation. For instance, CloseWellBuilding could be the specialization of

WellBuilding considering only the pairs separated by a distance shorter than a given

threshold. The object instances related by a specialized context are a subset of those

participating in its ancestor.

In GeoMDT, concept specialization is based on the following rules:

* Attribute restriction. The specialized concept, no matter whether value, object or

context, inherits the attributes of its upper level concept. Some of these could be

restricted, or in other words de®ned as specializations of the domain values, object

classes or context classes characterizing the homologous attributes of its ancestor. For

instance, the distance attribute of CloseWellBuilding can take only values lower than

the ®xed threshold, whereas in WellBuilding they can take any positive value.* Additional attributes. The specialized concept, no matter whether value, object or

context, can be characterized by additional attributes that model its speci®c properties.

The addition of these attributes must not modify the semantic level of the specialized


concept with respect to that of its ancestor (that is, specialization cannot transform a

value into an object or an object into a context). Consequently, an additional attribute

mapping onto a value domain is permitted in all cases, an additional attribute mapping

onto an object class can only enrich an object or a context, and an additional attribute

mapping onto a context class can only enrich a context.* Additional laws. Finally, the specialized concept, no matter whether value, object or

context, inherits the laws of its ancestor, but may differ from it due to the presence of

additional laws. As speci®ed below, laws are predicates constraining the concept state

and state variations: the presence of additional laws results in a restriction of the

concept dynamics.

4. Model syntax

The model syntax is provided in this section in the form of production rules. A full

characterization of the model instructions is beyond the scope of this paper, as strict formal

expressions are not critical in a requirement analysis language. A broader syntactical

presentation is reported in [24].

4.1. De®nition structure

The GeoMDT statements all share the same basic structure, made up of four main parts:

header, instance attributes, class attributes and laws.

* Header. The header speci®es the primitive type (namely value, object, context or

virtual) followed by the de®nition identi®er. If the concept is introduced by

specialization, the header reports the keyword isa followed by the identi®er of the

ancestor. Other header extensions apply respectively to context and virtual (see

Sections 5.3 and 5.4); they are the by clause and the argument list.

Header::�Primitive ConceptIdenti®er([ isa ConceptIdenti®er]j[by ConceptIdenti®er {, ConceptIdenti®er}]j[(Argument: ConceptIdenti®er {, Argument: ConceptIdenti®er})])

Primitive::� valuej object j context j virtual

* Instance attributes. This section draws together the attributes that characterize every

instance belonging to that class. An attribute is described by its identi®er followed by a

colon and the identi®er of the value, object or context domain it maps onto (or the

value domain given by subrange or enumeration). The keywords mandatory and

unique can be added to indicate, respectively, that the attribute must take on a value in

each instance, and that the value must be different in the various instances.


InstanceAttributes::� {InstanceAttribute}InstanceAttribute::�

AttributeIdenti®er: ([listof|setof]ConceptIdenti®erjSubrangejEnumeration) [mandatory ] [unique]

* Class attributes. This section draws together the attributes that characterize the set of

all instances that populate the class. The section starts with the sub-header ``classattributes''. Each attribute is described by its identi®er followed by a colon and the

identi®er of the value, object or context domain it maps onto. The attribute Instances,mapping onto the set of all the class instances, is implicitly de®ned but can be recalled

in this section.

ClassAttributes::� class attributes{ClassAttribute}ClassAttribute::� [Instances: setof all ConceptIndenti®er]j

AttributeIdenti®er: [listofjsetof]ConceptIdenti®er

* Laws. This section expresses the concept dynamics in the form of predicates de®ned

on the concept attributes and on the attributes of the component concepts. Laws

involving only instance attributes apply to the state of each instance, while those

involving class attributes apply to the set of all instances. The section starts with the

sub-header ``laws'' and is composed of two parts: the de®nition of work variables, if

present, precedes the concept laws. A label, followed by a colon, can identify each

law. Syntax and use of work variables and laws are detailed in the next section.

Laws::� laws [{WorkVariable}] {Law}Law::� [Label:] PredicateWorkVariable::� let VarIdenti®er�Expression

The graphical notation for the GeoMDT model is reported in ®gure 1. A GeoMDT schema

Figure 1. The model graphical primitives.


is a direct graph whose nodes represent the concepts of the pictured application and whose

branches represent the composition and specialization relations between them. The

composition arrows go from the component to the compound concepts, and the

specialization arrow goes from the specialized to the ancestor concepts. The virtual

composition arrow is only applied to building virtual objects. Both types of composition

arrow can be labelled by S to indicate that the components are a set, or by L to indicate that

the components are a list.

Although not strictly necessary, for the sake of readability it is useful to organize the

graph of the de®ned concepts from left to right in order of increasing semantic complexity.

4.2. Laws

As methods implement operations to be performed on object instances, they can be de®ned

only at an advanced stage of the application development process. On the other hand,

limiting the behavior representation solely to the method signatures cannot express all the

domain knowledge already available at the requirement analysis stage. This is the basic

reason why we decided to introduce laws to capture and formalize the dynamics of the

observed objects and inter-object relations. Generally speaking, the knowledge expressed

by GeoMDT laws concerns:

* constraints on states and state transitions of the de®ned concepts* dependencies between states and state transitions of component and compound

concepts.

Consider a concept X, no matter whether value, object, context or virtual. Let us denote by

Di the domain onto which the i-th of its m attributes maps. The space of the states of X, in

other words the set of all possible states, is de®ned by the Cartesian product:

S�X� � D16D26:::6Di6:::6Dm:

In practice, not all the possible states are legal: the ®rst step in dynamics representation is

to restrict S�X� to the space of legal states SL�X�.It may also occur that a state transition is not legal even though it moves between two

legal states. A state transition is represented by the pair of the states the concept presents

before and after the change: t � hs; s0i. The space of all the possible transitions is given by

the Cartesian product:

T�X� � SL�X�6SL�X�:

The space of legal transitions TL�X� is in turn a restriction of T�X�. In general, the

subsequent state could be conditioned by two or more previous states, or by the concept's

entire history. Here we only consider the dependency on the last state as it can include

attributes that summarize the history of previous transitions.


In short, the concept dynamics is de®ned by the restriction predicates ps and pt that

limit, respectively, the spaces of legal states and legal transitions. This means that

whenever an event occurs that changes the state of concept X from s to s0 the following

predicate must remain satis®ed:

P�X� � ps�s0� and pt�hs; s0i�:

A further aspect to be considered is the mutual dependency between the concept state and

the states of its components, if any. It may occur that the new X state, although legal and

legally reached, is not compatible with the states of its components, say A and B. In the

analogy with the above de®nitions, we introduce for X the extended state space S�X� and

the extended transition space Y�X�.

S�X� � S�X�6S�A�6S�B� Y�X� � T�X�6T�A�6T�B�:

The complete de®nition of concept X dynamics includes the predicates that limit the

extended spaces of legal states SL�X� and legal transitions YL�X�, and can be expressed in

the form:

P�X� � P�X� and P�XnA� and P�XnB� and P�XnA;B�

where P�XnA� and P�XnB� are logical expressions limiting the legality of A and B,respectively, when participating in X, and P�XnA;B� indicates the mutual limitations of Aand B within X.

This introduces a relation between the behavior of the compound concept and those of

its components. We assume that p�X� fully expresses the context-free behavior of concept

X. Whenever X participates as a component in higher complexity concepts, further

constraints will affect its behavior: these constraints must be coded within the respective

compound concept. With this modeling approach, GeoMDT ensures a ``nested

encapsulation'' of concepts, the bene®ts of which will be discussed later.

Observe that p�X� represents the X invariant. With the GeoMDT model it corresponds to

the conjunction of all the laws de®ned for X. Laws take the form of predicate calculus

formulas [1] whose terms are the attributes of the concept in discourse and the attributes of

its components. Each law can be seen as a further logical attribute; its true value must be

ensured in order to keep the concept legal.

An exhaustive representation of the law syntax is beyond the scope of this paper. The

following are the main de®nition rules:

Predicate::� (Predicate)jnot PredicatejPredicate LOp PredicatejFactorLOp::� andjorj)j,Factor::� LogicalTermjExpression ROp ExpressionjUnivQuanti®erjExistQuanti®erLogicalTerm::�AttributeIdenti®erjold AttributeIdenti®erROp::� eqjne j lt j le jgtjgejinUnivQuanti®er::� forall VarIdenti®er in SetExpression itis Predicate


ExistQuanti®er::� exists [unique] VarIdenti®er in SetExpression suchthat PredicateExpression ::� SetExpression j OtherExpressionSetExpression ::� AttributeIndenti®er j VarIdenti®er j SetExpression SOp SetExpression

j (unique j setof j listof ) VarIdenti®er in SetExpression where PredicateSOp ::� union j xunion j intersection j minus j includes

Concerning OtherExpression, its terms are attribute and variable identi®ers as well as

functions. As GeoMDT is requirement speci®cation oriented, it does not provide a list of

the permitted functions and operators: the application designer can use any of the functions

and operators available in programming languages and GIS systems. In addition to the

common numerical operators �� , ÿ , *, /� and functions (sqr, sqrt, exp, and so on),

particularly useful functions are those that act on sets and lists, such as cardinality, ®rst,

last, next, previous and more. Other useful functions are those that compute synthesis

values, such as minimum, maximum, sum or average, whose syntax is:

SynthesisFunction ::� FunctionIdenti®er(AttributeIdenti®er for VarIdenti®er in SetExpression where Predicate)

The examples given in the following chapter will provide a practical view of law syntax. In

particular, it is worth noting that state transitions can easily be written in the form of

implications using the old keyword. For instance, assuming that State and Event are

attribute identi®ers, we could have:

Law23: old State eq S3 and Event eq E14 ) State eq S4 and . . .

Last, but very important, the dot notation is adopted to denote the attribute identi®ers of

component concepts. The form A.X stands for `àttribute X of component A''.

5. Model application

In the following sections we present examples of application of the GeoMDT model. The

purpose is twofold: to complete the syntactical characterization of its instructions and to

provide a practical view of the outcome of its use. The examples do not describe

completely the introduced concepts, but simply show a sample of their attributes and laws.

The examples de®ne some properties of those concepts that are graphically represented

in the diagram of ®gure 2. As suggested, the diagram is pictured so as to draw the de®ned

concepts from left to right in order of increasing semantic complexity. Only virtual objects

are not subject to this rule. The concept diagram is drawn according to the graphical syntax

introduced in Section 4.1. For the sake of readability, the diagram does not include the

elementary values, namely Real, Integer, Boolean, String, as well as subsets and

enumerated values, and the relative composition relations.

The represented concepts offer a quite complete view of GeoMDT as they involve all

the model primitives. Geometrical concepts of increasing complexity (Point, Line,

ClosedLine, Network, Con¯uentTree, CRegion and QRegion) are ®rst introduced as

values. On this basis, some territory aspects are modeled as objects; they include spatial

entities (Well, RiverBranch and River) and space-varying properties (Rain, Slope and


Hazard) as specializations of RLayer. Then, a spatial relation among layers (RSHazard) is

modeled as context, while other contexts are shown in Section 5.3 and ®gure 4. Finally,

invariant relations found within groups of values (P&P, P&L and CR&CR) or within

groups of objects (Swells and RiverAndWell) are modeled as virtuals.

When modeling the application concepts, the designer often needs to refer to functions

acting on spatial properties and topological relations of objects. Most of them are made

available by common GIS systems, so they can simply be recalled without any explanation

of their logic. In order to distinguish these built-in functions from the other model terms,

they take the following form:

*functionName�Argumentf ; Argumentg�

where the function arguments are variable or attribute identi®ers referring to values.

5.1. Values

The elementary value domains of the GeoMDT model are Integer, Real, String, Booleanand similar, together with their subranges and the user-de®ned enumerations. When

introducing complex domains, the general de®nition structure (see Section 4.1) is

simpli®ed according to the following constraints:

* Header. The primitive identi®er is value, and possible ancestors cited in de®nitions by

specialization are in turn values.

Figure 2. Example of concept diagram.


* Instance attributes. The domains onto which these attributes map are in turn values,

and the mandatory and unique clauses do not apply.* Class attributes. As values are only instantiated within higher level concepts, class

attributes are meaningless.* Laws. Value laws aim to accurately characterize the domain extension.

Remember that state and identity of values coincide. This means that two values belonging

to the same domain are certainly equal if their states are equal.

Examples of complex values relevant to geographical applications are those introducing

geometrical concepts. For instance:

value PointX, Y: RealHeight, Slope, Orientation: ReallawsPT1: Height eq *dtmHeight(X, Y)

For the sake of clarity, we assume to de®ne the geometrical concepts from scratch, even

though most of them may be considered available as modeling primitives. The Point

concept is the basic building block; here we refer to the 2-D point, and consider height,

slope and orientation as quantities coming from the DTM system through the

corresponding computation functions.

value LinePath: listof PointStart, End: PointLength: RealSelfCrossing: BooleanlawsLN1: Start eq ®rst(Path) and End eq last(Path)LN2: Length eq sum(P&P(P1 � P, P2 � next�P�).Distance for P in (Path-last(Path)))LN3: SelfCrossing ,*lineSelfcrossing(Path)

Law LN1 should be self-explanatory. Law LN2 expresses the line path length by applying

the synthesis function sum to the distance property of the P&P virtual object

(corresponding to a generic pair of points, as we shall see in Section 5.4). Law LN3

recalls a hypothetical built-in function that, given a list of points, veri®es whether the line

joining them is self-crossing.

value ClosedLine isa LinelawsCL1: Start eq End

Law CL1 expresses the line closure constraint that holds for the specialized concept but

not for its ancestor.

value NetworkNodes: setof Point


Arcs: setof LinelawsNW1: forall N in Nodes itis (exists A in Arcssuchthat N eq A.Start or N eq A.End )

This value introduces (one of ) the topological rules of a generic network by establishing

relationships between nodes and arcs. A specialization of network is Con¯uentTree, which

corresponds to the case where arcs converge from a number of leaves to a unique root.

Here too we give a sample of the possible topological rules.

value Con¯uentTree isa NetworkRoot: PointLeaves: setof PointlawsCT1: forall N in (Nodes minus Root) itis (exists unique A in Arcs suchthat N eqA.Start)

This example, like the previous ones, shows how the modeler can use the value primitive

(and the virtual primitive, as we shall see) to capture the large quantity of knowledge that

refers to geometrical and topological properties of spatial objects. To ignore this aspect of

requirement speci®cation would results in an exceedingly poor geographical information

system design.

5.2. Objects

As central GeoMDT concept, object can be de®ned by using all the elements of the general

de®nition structure. In particular:

* Header. The primitive identi®er is object, and possible ancestors cited in de®nitions by

specialization are in turn objects.* Instance attributes. The domains onto which these attributes map are values or objects,

respectively representing object properties or object components.* Class attributes. Like instance attributes, class attributes map onto values or objects.

Proper synthesis and selection laws relate instance and class attributes.* Laws. Object laws aim to accurately characterize the constraints that must be satis®ed

by instances belonging to the object class.

Object state and identity are distinct aspects. Two object instances coincide if they have

the same identity. GeoMDT expresses this possibility by comparing object identi®ers,

which are denoted by the ident() function; ident(X) represents the instance X identity.

Examples of object de®nitions relevant to geographical applications are those that

introduce spatial entities with their geometrical properties. For instance:

object RiverBranchCode: StringShape: Line


Length: ReallawsRB1: not Shape.SelfcrossingRB2: Length eq Shape.LengthRB3: forall Ba, Bb in Instances itis (ident(Ba) ne ident(Bb) ,

not L&L (L1�Ba.Shape, L2�Bb.Shape).Intersect)

Laws RB1 and RB2 should be self-explanatory. Law RB3 refers to a class property

according to which river branches cannot intersect with each other: it applies to all the

river branch instances, regardless of the rivers they belong to. For this purpose, we recall

the intersection property of a generic pair of lines (the L&L virtual object) where each line

represents the shape of a river branch. Note that the condition ident(Ba) ne ident(Bb)avoids comparing a river branch with itself.

In order to model the composition relation between a river and its branches, it is useful

to introduce the river as a net of connected branches:

object RiverName: StringShape: Con¯uentTreeMouth: PointBranches: setof RiverBranchlawsRV1: Mouth eq Shape.RootRV2: forall B in Branches itis (exists A in Shape.Arcs suchthat B.Shape eq A)RV3: forall A in Shape.Arcs itis (exists B in Branches suchthat B.Shape eq A)

Laws RV1, RV2 and RV3 relate the shape property of the river to the homologous property

of the component branches. The dependency between object and component attributes is

very common. Other laws could be written to capture further river properties, for instance

the fact that its mouth is placed on the sea border or on the path of another river.

In order to represent object dynamics, let us model Well and suppose that its state is

affected by water quality, according to the state diagram of ®gure 3.

object WellCode: StringLocation: PointDepth: RealWaterQuality: (poor, fair, good)Status: (open, active, check, closed)class attributesActiveAvgDepth: ReallawsWL1: old Status eq open and WaterQuality in ( fair, good) ) Status eq activeWL2: old Status in (open, active, check) and WaterQuality eq poor ) Status eq closedWL3: old Status eq closed and WaterQuality eq fair ) Status eq check


WL4: old Status eq check and WaterQuality eq good) Status eq activeWL5: ActiveAvgDepth eq avg(W.Depth for W in Instances where Status eq active)

Note the presence of the class attribute ActiveAvgDepth, and law WL5 relating it to the

Depth attribute of the selected instances.

As regards the well-known object vs ®eld dichotomy [10], the GeoMDT approach

applies the same modeling principle to both cases. In the case of space-varying

(continuous) properties, such as slope or rainfall, we adopt the rule of choosing the layer as

the basic building block. This solution is different from others proposed in the literature

[30], expressing space-varying attributes as functions mapping from the spatial domain to

the property value range. Let us introduce the concept of region layer:

object RLayerTheme: StringLegend: setof StringZones: setof QRegionlawsLY1: forall Z in Zones itis (exists X in Legend suchthat Z.Quality eq X)LY2: forall Z1, Z2 in Zones itis (Z1.Quality ne Z2.Quality )not CR&CR(R1� Z1.Extent, R2� Z2.Extent).Intersect)

where QRegion stands for quali®ed region:

value QRegionQuality: StringExtent: CRegion

It associates the value of a spatial property (Quality) to the region where it is observed

(Extent). CRegion (complex region) is a value in turn, indicating a collection of disjoint

polygons. Law LY1 establishes that the legend expresses the attribute values observed in

the different layer zones, while LY2 adds a further constraint according to which two

distinct layer zones do not overlap.

Figure 3. State diagram of Well.


Rain, Slope and Hazard are now introduced as specializations of RLayer, in preparation

for their use in Section 5.3. They obviously inherit all the instance and class attributes of

RLayer, as well as the de®ned laws. In particular, Theme and Legend are rede®ned by

restriction to limit their value domains.

object Rain isa RLayerTheme: ``three levels rainfall''Legend: f`` � 10''; ``11 to 50''; ``450''gobject Slope isa RLayerTheme: ``four levels slope''Legend: f``0 to 1''; ``2 to 10''; ``11 to 25''; ``425''gobject Hazard isa RLayerTheme: ``hazard from rain and slope''Legend: f``low''; ``medium''; ``high''gIn Section 5.3 these objects are placed in relation with each other by a proper context. This

shows how the GeoMDT approach allows the application modeler to capture and make

explicit the dependencies between basic and derived thematic maps, a knowledge that

usually remains hidden within the application algorithms.

5.3. Contexts

Relations carry a large amount of knowledge since geography behaves as the common

property of all spatial objects. Thus, in requirement engineering and design, particular

attention should be paid to modeling object relations and the underlying conditions

involving object attributes.

In the analogy with objects, contexts can be de®ned by using all the elements of the

general de®nition structure. In particular:

* Header. The primitive identi®er is context, and possible ancestors cited in de®nitions

by specialization are in turn contexts. The context primitive can introduce derived

relations. A derived relation directly links concepts that are already indirectly related

by one or more contexts. In this case, the clause by is used to recall the concepts

(objects and contexts) from which the new context derives.* Instance attributes. The domains onto which these attributes map are values ( for

de®ning context properties), or objects or contexts ( for specifying the concepts

participating in the relation).* Class attributes. Like instance attributes, class attributes map onto values or objects.

Proper synthesis and selection laws relate instance and class attributes.* Laws. Context laws aim to accurately characterize the constraints that must be satis®ed

by instances belonging to the context class.

Examples of context de®nitions relevant to geographical applications are those

introducing or using topological relations. For instance, the RSHazard context explains


how a three-level rainfall classi®cation and a four-level slope classi®cation can be

combined to express the three-level Hazard theme. The following table expresses the

intended value correspondence.

Rain vs. Slope ``0 to 1'' ``2 to 10'' ``11 to 25'' ``4 25''

``� 10'' ``low'' ``low'' ``medium'' ``medium''

``11±50'' ``low'' ``medium'' ``medium'' ``high''

``4 50'' ``medium'' ``high'' ``high'' ``high''

context RSHazardR: RainS: SlopeH: Hazardlawslet RN1� unique Z in R.Zones where Z.Quality eq ``� 10''

let SL1� unique Z in S.Zones where Z.Quality eq ``0 to 1''

let HZ1� unique zZ in H.Zones where Z.Quality eq ``low''

let R1S1�CR&CR(R1�RN1.Extent, R2� SL1.Extent).IntersectionRS1: CR&CR(R1�HZ1.Extent, R2�R1S1).Includes

Law RS1 says that the CRegion resulting from the intersection between the extents of

the lowest rainfall and slope values, denoted as R1S1, is included in the extent of the

``low'' hazard value (Includes is a Boolean attribute of CR&CR). Analogous laws are

required to de®ne the other combinations of rainfall, slope and hazard values as reported in

the above table.

The same approach can be used to relate more than three themes to each other and to

rede®ne a theme according to a different value scale. This gives a conceptual

representation of the map derivation process that, however, could be simpli®ed if

assuming that operators between layers are already provided as built-in functions by the

underlying GIS technology. This could replace all the RSHazard laws with the only law:

RS: H.Zones eq *qregionOverlay (R.Zones, S.Zones, Tab)

where Tab corresponds to the above table.

Contexts are also used to express non-topological relations. For instance, suppose that a

number of water management agencies exist, each of which controls a set of wells and a

set of river branches, independently of where they are located. The contexts WellMngt and

RBrMngt, reported in ®gure 4, represent these relations.

context WellMngt context RBrMngtA: Agency A: AgencyW: Well B: RiverBranch

More interesting, the knowledge expressed by these contexts can be used to introduce a

derived relation (WellRB) between wells and river branches: it is the relation that

associates each agency to the set of wells and the set of river branches it manages.


context WellRB by WellMngt, RBrMngtA: AgencySW: setof WellSB: setof RiverBranchItems: IntegerlawsWB1: forall Wx in SW itis (exists WM in WellMngt.Instances suchthat

(ident(A) eq ident(WM.A) and ident(Wx) eq ident(WM.W)))WB2: forall WM in WellMngt.Instances itis (exists WB in WellRB.Instances suchthat

(ident(WB.A) eq ident(WM.A) and exists Wx in WB.SW suchthat(ident(Wx) eq ident(WM.W))))

... ... ... ... ... ... ... ... ...

WBi: Items eq cardinality(SW)� cardinality(SB)

5.4. Virtuals

Virtual objects are used to formalize general aspects and regularities in the mutual

relations within groups of values or objects. As they are not instantiated, their de®nition

does not include class attributes:

* Header. The primitive identi®er is virtual, and possible ancestors cited in de®nitions

by specialization are in turn virtuals. For this primitive the header is completed by the

list of arguments (mandatory), in other words the concepts put in relation by the virtual

object. A pair hrole name, concept typei speci®es each argument, where the concept

types indicates the value, object or context playing that role. Arguments are

instantiated whenever the virtual object is recalled to use the properties it carries.* Instance attributes. Besides the concepts cited in the argument list, which in fact act as

main components of the virtual object, further properties and components can be

Figure 4. Non-topological and derived contexts.


de®ned as instance attributes. They are related by proper laws to the argument

components and their attributes.* Laws. Virtual laws aim to accurately characterize properties and dependencies of the

values or objects they relate.

Examples of virtual de®nitions relevant to geographical applications are those relating

values to express geometrical properties. Here we report some of them.

virtual P&P (P1, P2: Point)Distance: ReallawsPP1: Distance eq*pointDistance (P1, P2)

Law PP1 establishes the correspondence between the distance attribute of any pair of

points and the outcome of the function pointDistance (typically provided by the GIS

system) which, given the co-ordinates of the points, computes their distance. Law LN2 of

the Line value is an example of use of this attribute. Analogously, the relation between a

generic point and a generic line can be expressed by the following virtual. In addition to

the distance attribute, taken as the minimal distance, a Boolean attribute can be used to

denote whether the point belongs to the line.

virtual P&L (P: Point, L: Line)Includes: BooleanMinDistance: ReallawsPL1: Includes , *linepointInclusion (L, P)PL2: MinDistance eq *linepointDistance (L, P)

P&L is recalled in law RW1 of the RiverAndWell virtual object de®ned below.

Other virtual objects mentioned in the examples are L&L (L1, L2: Line), relating two

generic lines to express properties such as their intersection, and CR&CR (R1, R2:

CRegion), relating two generic complex regions to express properties such as intersection,

union and inclusion. In particular, the latter is widely used in de®ning dependencies

between layers.

As anticipated, virtuals can also formalize the dependencies observed within groups of

objects. For example, a generic set of wells shows attributes such as average depth,

calculated from the attribute depth of each well.

virtual SWells (S: setof Well)AvgDepth: ReallawsSW1: AvgDepth eq sum(W.Depth for W in S) / cardinality(S)

Finally, a virtual object can be de®ned to express the general features of the pair made of a

generic well and a generic river. For instance, the distance attribute can be de®ned by using

the minimum distance property of the lines, representing the shapes of the river branches,

with respect to the point representing the well location.


virtual RiverAndWell (R: River, W: Well)Distance: ReallawsRW1: Distance eq min(P&L(P � W:Location, L � B.Shape).MinDistance for B. inR.Branches)As a consequence, in compound objects or contexts, where river and well appear as

components, calls like this can be found:

Lawi: . . . RiverAndWell(R � Riverx;W � Welly).Distance gt 1200 . . .

6. Modularity and reuse

In this chapter we show how GeoMDT modeling of the application domain yields to a

modular and highly reusable design. The bene®ts of the proposed approach are:

* representation independence of the GIS technology that will be adopted for system

development,* easy identi®cation of the functions that will serve as routines in the code that realizes

the application,* effective guide to the design of data structures and management code that mirror the

GeoMDT schema modularity,* high reuse potential of the application design and implementation thanks to the

adoption of the nested encapsulation method.

Each of these aspects is explained in more detail and discussed.

6.1. Independence of the GIS technology

The introduction of values, together with their attributes and relations expressed by

virtuals, aims to create the building blocks that are required to model objects and themes of

the application domain. Particularly critical is the de®nition of their spatial properties and

relations, as they express a large part of the knowledge that the application is to manage.

Given the nature and complexity of spatial attributes, the functions for elaborating them

are also complex. GIS technology already provides most of these functions, even though

the function sets made available by the different GIS systems do not completely overlap.

The ®rst modeling task for achieving independence of the speci®c technology is to con®ne

the reference to these functions. The approach we propose involves recalling these

functions only within values and virtuals, following three possible lines of action:

* If the technology is already known at the requirement analysis stage, then in de®ning

values and virtuals it is convenient to start from the list of the functions that the chosen

technology provides. Spatial values and virtuals will be affected by the reference to


this list, but objects and contexts that use them will be independent from the

technology.* If we intend to develop the application on different previously identi®ed GIS

platforms, then it is convenient to start from the function lists that each technology

offers and to realize the corresponding versions of spatial values and virtuals.

Comparison between these versions ¯avors identifying those aspects that depend on

the single technology and those that are invariant that, consequently, could be

designed once for all.* Finally, if the choice of the GIS system occurs after the modeling stage, it is in any

case possible to proceed with a detailed requirement speci®cation activity, as in the

previous examples. As soon as the need to recall GIS functions arises, these are

introduced with a proper syntactical notation: the list obtained at the end of the

modeling work constitutes a clear and complete indication for the application

designer.

Whatever the chosen line of action, object and context de®nition is not affected by the GIS

platform used, and many of the value and virtual properties can also be developed

independently of the GIS technology.

With reference to the third of the above lines of action, observe that the examples given

in the previous chapter produce the following list of GIS functions:

*dtmHeight (X:Real, Y:Real): Real*lineSelfcrossing (LP: listof Point): Boolean

*pointDistance (P1, P2: Point): Real*linepointInclusion (L: Line, P:Point): Boolean*linepointDistance (L: Line, P:Point): Real

where the pre®x dtm denotes the functions that compute spatial properties depending on

the digital terrain model of the GIS system. The values and virtuals that recall them

provide the required information on their type and arguments: it is the designer's task to

adapt these de®nitions to the data and function types of the GIS technology that eventually

will be chosen.

Figure 5. Value and virtual attributes as functions.


6.2. Easy identi®cation of routines

A further contribution of values and virtuals to de®ning modular and reusable code arises

from their ability to capture the observed regularities in the behavior of objects and

contexts. Remember that values and virtuals are not instantiated alone, but they are used to

characterize spatial properties and topological relations of objects and contexts. When

moving to the design and development phase, their modeling provides useful hints for

de®ning application routines.

Consider the Line value and the RiverAndWell virtual introduced in the previous

chapter. The respective attributes Length and Distance can be interpreted as functions, as

shown in ®gure 5. The logic of these functions is given by the laws that cite such attributes:

some of them are very simple, for instance when they simply recall a built-in GIS function,

whereas others can be quite complex.

It is useful to code them in the form of routines, the execution of which will be invoked

whenever the corresponding attribute is cited in the higher level concept.

A ®rst advantage offered by this solution is the possibility of obtaining precise hints on

the frequently used functions required by the application at an early stage of the

development cycle. Some of them refer to new complex spatial data types, which must be

introduced along with those offered by the GIS technology, while others concern relevant

aspects of the interactions of objects and contexts. Realizing this function library

accelerates the development process and ¯avors the adoption of a disciplined coding

method.

Another advantage arises from the possibility that many of the concepts de®ned by the

GeoMDT model are suf®ciently general to be useful in future applications. If library

functions are placed in strict correspondence with attributes and laws, their reuse becomes

easier and then more frequent. Reuse is also favored by a better understanding of what

each routine does: in place of a cryptic signature, the set of laws translated by the routine

provides semantically rich, unambiguous and, very importantly, readable expressions.

6.3. A guide to modular design

As far as objects and contexts are concerned, the schema obtained by applying the

GeoMDT model provides a fundamental contribution to a modular de®nition of data

structures and code. In an object-oriented environment every object and context should be

coded as a module, in other words a data structure together with the functions to manage it.

Attributes and laws of the concept indicate which data structure is required to store its

instances and to link them, typically by pointers, to the instances of the related concepts.

Moreover, laws indicate which methods are required to update data and ensure their

correctness.

(Incidentally, analogous support is obtained when using the GeoMDT schema to design

the application in a traditional environment, such as that based on the relational and GIS

technologies. Albeit less directly, the GeoMDT representation helps the relational design

of data structures and the functional design of the code that ensures data consistency.)


The translation of laws into module methods is straightforward, according to the

following considerations.

* The conjunction of all the laws of a given concept expresses the concept invariant,

which determines the conditions that must remain satis®ed after any state change of its

instances. In other words, laws behave as post-conditions to be applied to every

instance when it undergoes a state change. If a law is violated, a restoration action

must be undertaken with the ultimate aim of reaching a legal state through a legal

transition. If two or more laws of a given concept are simultaneously violated, the

corresponding restoration actions must all be executed.* A restoration action is generally inspired by the law that triggers it: it modi®es some

instance attributes so that the law is once again satis®ed. In doing this, the action can

cause violation of other laws of the same concept. What should be veri®ed is that law

effects, individually or in combination, are consistent and lead to a ®nal legal state.

Furthermore, the state reached should be independent of the law issuing order or, at the

very least, proper ordering criteria should be derived from a law serialisability analysis

[11], [24].

In order to meet these requirements, we classify laws according to their mutual

dependencies and show how the different law categories are characterized by speci®c

serializability conditions. For this purpose we assume that the action associated with a

given law is an operation that maps the input state used to evaluate the law into a new state.

If the action is in itself correct, the output state will always be legal with respect to the

condition expressed by the law triggering it. Moreover, we have two different ways of

coding laws and their restoration actions into methods:

* Local. At every state change all these methods are invoked. Each of them checks the

associated law and, if it is violated, executes the restoration action. Thus, the single

method acts on the state generated by the previously applied method.* Global. At every state change a proper method checks all the laws and sets ¯ags

corresponding to those that are violated. Only the methods whose ¯ag is set are

invoked to execute the associated action. Thus, all the laws are checked with respect to

the state determined by the initial change.

According to these coding approaches, there are three law categories that ensure that a

legal ®nal state is reached: exclusive laws, locally independent laws, and globally

independent laws. Laws not belonging to these categories may introduce serialisability

problems and hence must be rewritten.

* Exclusivity. This case occurs if, in every situation, only one of the object laws may be

violated and execution of the associated action does not violate other laws.* Local independence. This case occurs if the ®nal state, obtained after invocation of all

the methods, coded according to the local approach, is independent of the execution

order and legal for all the laws.


* Global independence. This case occurs if the ®nal state, obtained after invocation of

all the methods, coded according to the global approach, is independent of the

execution order and legal for all the laws. This result can be achieved even if the

action of a law, violated by the state resulting after the last executed action, is not

executed because the initial state, on which basis laws are evaluated, is legal for it.

Figure 6 represents the relationships existing between the law categories de®ned above. A

law belongs to one of the represented classes if it presents the relative independence

property with respect to all the other object laws. Observe that only a subset of locally

independent laws are also globally independent, and vice versa.

Once object laws have been classi®ed in the above independence categories (and

unclassi®able laws have been rewritten), code generation can be carried out on the basis of

the classi®cation criteria themselves. Suppose that n laws, subdivided into three disjoint

groups, describe the object behavior:

* A group: laws L1 to Lh satisfying the exclusivity condition with respect to all the nlaws,

* B group: laws Lh�1 to Lm satisfying the local independence condition with respect to

all the n laws,* C group: the remaining laws Lm�1 to Ln satisfying the global independence condition

with respect to all the n laws.

The resulting code structure for the concept of discourse is the following:

if not L1 then execute A1 elseif not L2 then execute A2 else... ... ...

if not Lh then execute Ah elsebeginif not Lh�1 �S0� then execute Ah�1

if not Lh�2�s0� then execute Ah�2

... ... ...

if not Lm�s0� then execute Am

Figure 6. Relationships between law categories.


if not Lm�1 then execute Am�1

if not Lm�2 then execute Am�2

... ... ...

if not Ln then execute An

end

where Ai indicates the restoration action associated with law Li, and s0 represents the state

before execution of the methods that ensure the instance legality. Note that, by the

exclusivity property, when a law of group A is violated the remaining laws will not be

considered.

6.4. Nested encapsulation

Finally, it is worth examining in greater depth how the knowledge organization resulting

from application of the GeoMDT model ensures a high potential for reusing the de®ned

concepts. Remember that reuse requires a design where each module is independent of the

number and variety of the modules that use its methods (clients), and remains visible for

further interactions with other modules. It means that no data structure and method

modi®cations should be required when adding a new client module or coding a new inter-

module dependency. An intuitive way of pursuing these objectives is to base module

design on the following rules:

* No cross-reference shall be established between modules so that, if module X is a

client of module Y then module Y will not be aware of the existence of module X.* The methods of every module shall ensure the correctness of its data and the

consistency of these data with those of its components.

With reference to the above rules, the knowledge of the behavior of every concept is split

between the module that realizes the concept itself and the modules that consider the

concept as a component (its clients).

In ®gure 7 module A is client of modules B and C and module D is a component of C.

Figure 7. Behavior representation across modules.


The notation b�X� stands for ``behavior of concept X taken alone'', b�X?Y� stands for

`ìnterdependency between X and Y states'', b�YnX� stands for `` behavior of Y within X''.

The client-free behavior of each concept is coded in the relative module, while the

client-dependent behavior is coded in the modules of the respective clients. Rather than

being a problem, this subdivision ¯avors modularity and hence code reusability. Indeed, it

ensures that each concept is designed to include just its own features and the rules relating

it to its components, if any. This results in what is called nested encapsulation. Nested

encapsulation provides various levels of reuse:

* an object without components is reusable on its own,* a compound object or a context can be reused as it is, provided that its components are

reused with it,* reusable modules of increasing size are obtained as the complexity of compound

objects and contexts increases.

Incidentally, this organization satis®es the principle of understandibility of the single

module and helps to produce units with few interfaces with other modules [22].

7. Conclusions

We have seen that, in the perspective of reuse, the GeoMDT model helps to identify

modules of different complexity, characterized by strong internal cohesion and weak

coupling with other modules. The resulting schema can easily be translated into relational

or object-oriented data organizations, and laws provide effective hints for function and

method coding. The proposed approach can overcome the wide gap that is presently found

between the rough representation of the application domain, obtained by traditional

methods, and the detailed knowledge that should support system development.

The examples given in the paper con®rm that by modeling spatial objects and their

relations, no matter how complex the objects are, and by expressing regularities and

constraints in the form of predicate calculus formulas, it is possible to capture most of the

knowledge coming from the collected system requirements. Because of the intrinsic

complexity of the subject, and the detailed representation provided by the GeoMDT

model, the result of this activity is a wide and rich formalized schema. Although the

schema may be considered burdensome to create, it is extremely valuable for the

knowledge it brings to the design and implementation phases.

The GeoMDT model has been applied in designing the Geographic Information System

of the Italian National Geologic Survey [3] and in environmental applications [4]. It is

currently being used for the execution of the ISOLA project (Information System for the

Orientation of Local Actions) of the European research programme LIFE. A preliminary

version of a computer-aided tool supporting the GeoMDT model is presently running; an

improved version that takes advantage of the experience acquired up to now is under

development and will be available in a few months time.


References

1. E. Bertino et al. `Òbject-Oriented Query Languages: the Notion and the Issues,'' IEEE Transactions onKnowledge and Data Engineering, Vol. 4(5):1992.

2. F. Bonfatti. `Ìntensional Design of Geographical Information Systems,'' in Proc. EGIS 93, Genova, Italy,

1993.

3. F. Bonfatti, A. Dallari, and P.D. Monari. ``Capturing more Knowledge for the Design of Geological

Information Systems,'' in Proc. ACM-GIS 95, Baltimore, USA, 1995.

4. F. Bonfatti and P.D. Monari. ``Spatio-Temporal Representation of Complex Geographic Structures,'' in

Computer Support to Environmental Impact Assessment, Guariso and Page eds., IFIP Transactions B-16,

North Holland, 1994.

5. M. Bunge. Treatise on Basic Philosophy (Ontology I and II), Vol. 3 and Vol. 4, Reider Publ.: Boston, 1977.

6. G. Camara et al. `À Model to Cultivate Objects and Manipulate Fields,'' in Proc. ACM-GIS 94, Maryland,

USA, 1994.

7. E. Clementini, P. Di Felice, and P. van Oosterom. `À Small Set of Formal Topological Relationships

Suitable for End-User Interactions,'' in Proc. SSD 93, 1993.

8. P. Coad and E. Yourdon. Object-Oriented Analysis. Prentice-Hall: New Jersey, 1991.

9. S. Cockroft. `À Taxonomy of Spatial Data Integrity Constraints,'' Geoinformatica, Vol. 1(4):327±343,

Kluwer, 1997.

10. H. Couclelis. ``People Manipulate Objects (but Cultivate Fields): beyond the Raster-Vector Debate in GIS,''

in Theories and Methods of Spatio-Temporal Reasoning in Geographic Space, Frank Campari and

Formentini eds., LNCS 639, Springer Verlag, 1992.

11. C.J. Date. An Introduction to Database Systems. Addison Wesley, 1981.

12. J.L. De Oliveira, F. Pires, and C.B. Medeiros. `Àn Environment for Modeling and Design of Geographic

Applications,'' GeoInformatica, Vol. 1(1):29±58, Kluwer, 1997.

13. M.J. Egenhofer. ``Spatial SQL: a Query and Presentation Language,'' IEEE Transactions on Knowledgeand Data Engineering, Vol. 6(1):86±95, 1994.

14. M.J. Egenhofer and K. AI-Taha. `Àbout Gradual Changes of Topological Relationships,'' in Theories and

Methods of Spatio-Temporal Reasoning in Geographic Space, Frank Campari and Formentini eds., LNCS

639, Springer Verlag, 1992.

15. U. Frank. ``Radial Categories Applied to Object-Oriented ModelingÐa Case Study for a Property

Registration System,'' in Proc. SAMOS 95, Samos Island, Greece, 1995.

16. E. Gamma, R. Helm, R.E. Johnson, and J. Vlissides. Design Patterns, Elements of Reusable Object-oriented

Software. Addison Wesley: Reading, MA, 1994.

17. T. Hadzilacos and N. Tryfona. ``Logical Data Modeling for Geographical Applications,'' InternationalJournal of Geographical Information Systems, Vol. 10(2):179±203, 1996.

18. G. Kosters, B. Pagel, and H. Six. `Òbject-Oriented Requirements Engineering for GIS Applications,'' in

Proc. ACM-GIS 95, Baltimore, USA, 1995.

19. G. Kosters, B. Pagel, and H. Six. ``GIS-Application Development with GeoOOA,'' International Journal ofGeographical Information Science, Vol. 11(4):307±335, 1997.

20. C. Lecluse and P. Richard. ``The O2 Data Model,'' Technical report Altair, 39±89, Le Chesnay, France,

1989.

21. B. Medeiros and M.J. Andrade. `Ìmplementing Integrity Control in Active Databases,'' The Journal ofSystem and Software, Vol. (12):171±181, 1994.

22. B. Meyer. Object-Oriented Software Construction, Prentice-Hall: New Jersey, 1988.

23. P. Milne, S. Milton, and J.L. Smith. ``Geographical Object-Oriented DatabasesÐa Case Study,''

International Journal of Geographical Information Systems, Vol. 7(1):39±55, 1993.

24. R. Montanari. Modular Design of Reusable Software: an Invariant-Based Approach, Ph.D. Thesis (in

Italian), University of Modena, 1998.

25. D. Papadias and T. Sellis. ``Qualitative Representation of Spatial Knowledge in 2-D Space,'' Very LargeDatabase Journal, Vol. 3(4):1994.

26. Q-labs (ed.). Reboot Methodology Handbook, Technical Report 8218, 1993.


27. J. Raper and D. Livingstone. ``Development of a Geo-Morphological Spatial Model Using Object-Oriented

Design,'' International Journal of Geographical Information Systems, Vol. 9(4):359±383, 1995.

28. J. Rumbaugh et al. Object-Oriented Modeling and Design. Prentice-Hall: New Jersey, 1991.

29. J. Sametinger. Software Engineering with Reusable Components. Springer-Verlag, 1997.

30. N. Tryfona and T. Hadzilacos. ``Geographic Applications Development: Models and Tools for the

Conceptual Level,'' in Proc. ACM-GIS 95, Baltimore, 1995.

31. Y. Wand. `À Proposal for a Formal Model of Objects,'' in Object-Oriented Concepts, Databases and

Applications, Kim and Lochowsky eds, Addison Wesley: Reading, MA, 1989.

32. M.F. Worboys. `Òbject-Oriented Approaches to Geo-Referenced Information,'' International Journal ofGeographical Information Systems, Vol. 8(4):385±399, 1994.

33. M.F. Worboys, H.M. Hearnshaw, and D.J. Maguire. `Òbject-Oriented Data Modeling for Spatial

Databases,'' International Journal of Geographical Information Systems, Vol. 4(4):369±383, 1990.

Flavio Bonfatti is Associate Professor of Software Engineering at the University of Modena and Reggio

Emilia, in Italy. His principal research interest is in object-oriented models for requirement analysis and design of

complex applications, including GIS applications. He is presently leading some research projects funded by the

European Union programmes Esprit and Life.

Paola Daniela Monari is lecturer of Industrial Applications of Computers at the University of Modena and

Reggio Emilia, in Italy. Besides acting as consultant for private and public bodies, she participates in national and

European R&D projects by applying software engineering techniques to software prototype construction.


Roberto Montanari received his Ph.D. in Software Engineering at the University of Modena and Reggio

Emilia, in Italy, with a thesis on modularity and reuse of design and code in object-oriented applications. He is

presently with Infoter, a software house working in the ®eld of support to logistics and manufacturing.


Documents

Requirement Analysis for the Definition of Reusable Spatial Objects