View
220
Download
0
Category
Preview:
Citation preview
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: sata@mo.nettuno.it
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
308 BONFATTI, MONARI, AND MONTANARI
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,
REQUIREMENT ANALYSIS 309
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
310 BONFATTI, MONARI, AND MONTANARI
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
REQUIREMENT ANALYSIS 311
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.
312 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 313
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.
314 BONFATTI, MONARI, AND MONTANARI
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
REQUIREMENT ANALYSIS 315
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 ``attribute 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
316 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 317
* 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
318 BONFATTI, MONARI, AND MONTANARI
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
REQUIREMENT ANALYSIS 319
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
320 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 321
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
322 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 323
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.
324 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 325
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
326 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 327
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.)
328 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 329
* 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.
330 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 331
The notation b�X� stands for ``behavior of concept X taken alone'', b�X?Y� stands for
``interdependency 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.
332 BONFATTI, MONARI, AND MONTANARI
References
1. E. Bertino et al. ``Object-Oriented Query Languages: the Notion and the Issues,'' IEEE Transactions onKnowledge and Data Engineering, Vol. 4(5):1992.
2. F. Bonfatti. ``Intensional 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. ``A 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. ``A 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. ``A 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. ``An 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. ``About 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. ``Object-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. ``Implementing 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.
REQUIREMENT ANALYSIS 333
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. ``A 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. ``Object-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. ``Object-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.
334 BONFATTI, MONARI, AND MONTANARI
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.
REQUIREMENT ANALYSIS 335
Recommended