International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
control
dimension
information service
rez? {product}
design problem
We
{set of requirements} ^ €
process
process
dimension
data
dimension service realisation
ange bent
Figure 3: Modelling dimensions
e data elements;
e processing elements; and
e connecting elements.
The data elements represent the information that is used,
manipulated and/or generated by the system. The process
elements represent the geo-processing capabilities of the
GSI system, which can perform transformations on data el-
ements. The connecting elements are like mediators, they
represent the relationships between other elements. The
connecting elements represent the conditions and con-
straints that define how the different elements may inter-
act and how they are organised with respect to each other
in a service specification. A similar approach to system el-
ements can be found in (Perry and Wolf, 1992, Fielding,
2000).
To illustrate the differences between these elements we can
use metaphorical example. Consider the games of soccer
and handball. The two games are similar in structure, they
use a ball as data element and players as processing ele-
ments. The difference between them lies in how these ele-
ments are allowed to interact with each other, which are the
context and rules of the games (the connecting elements).
These connecting elements are defined by game designers
based on what they want to achieve with the interactions.
Separation of concerns is the principle behind this mod-
elling dimensions. For example, by separating the con-
cerns on the nature and state of data from the data process-
ing concerns, we simplify the processing elements allow-
ing them to change and evolve independently. In the same
way portability of the data is improved by avoiding that
the data remain encapsulated and hidden within process-
ing elements. However, the drawback is that we lose the
advantages of information hiding and therefore a mecha-
nism is required for processing elements to identify and
understand the data types.
The origin of the reference system determined by the mod-
elling dimensions in Figure 3 represents the starting point
of a development process. The process is activated by a
design problem. Design problems represent the various
inputs (requests) to the GSI system that have to be con-
verted into services. A service has to be specified before
it can be realised. The path taken through the cube shown
in Figure 3 corresponds to the functional specification of a
service that satisfies a specific design problem using an ap-
propriate arrangement of components. The execution ofa
predefined service specification generates the desired ser-
vice.
4 GSI REPOSITORY
Our approach to geo-information services design focuses
on the use of conceptual models as an intermediate step
in the development process, which sit in between require-
ments and the actual implementation. The purpose of this
step is to obtain a conceptual description also called ab-
stract specification of system functions (internal or exter-
nal). This is done solely to enable and facilitate reuse and
to enhance flexibility.
The main benefit of these models is to serve as the basis for
the specification of complex services. If a model properly
describes an architectural element, that is, with the rele-
vant information at the correct level of detail to enable one
to determine what it does and how to access the function
it provides, then this architectural element can be easily
reused. By reuse of architectural elements, we mean the
inclusion of previously designed element in multiple ser-
vice definitions. We use constraint-oriented composition to
combine multiple architectural elements (Morales Guarin,
2004). This way it is possible to assemble large processing
chains by correctly combining models of (generic) archi-
tectural elements to form more specialised specifications
(service models) with the intention of provide more spe-
cific or particular services (see Figure 4).
Since the models of architectural elements prescribe the
behaviour exhibited by individual elements, a service model
can be used to choreograph the realisation of the service
specified in the model. Additionally, once a service model
is available it can itself be reused, as a generic element, in
another definition as a part of a yet more specialised ser-
vice. Reuse and flexibility is ultimately achieved by devel-
oping, sharing and integrating well-defined models of all
composing elements of the system.
For this approach to work, models need not only to be
interchanged between participants, but they also have to
be understood by all parties involved. This can only be
architectural j i í a veeern 4
elements { j eed L
i
v v
models of . RTT
; ^ ; N CN UN nan es
architectural NM < X y Nee x
elements t
1 4
j
Y Y xv v v v y v v y Y
gene rc
speci fic
Figure 4: Architectural elements, element models and ser-
vice models
1230
Interne
Figur
achiev
Such r
stract :
of the
enable
pliant
reposit
The re
differe
these r
vice m
A met:
relation
system
cept, al
can be
cept rej
or syst
of a sy
should
Relatio
ways ir
concep!
Which
elling n
designi
able foi
vironmé
compos
the con!
tionality
an
wh
gle
® tO]
dif
€ 101
abs
