International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
carrier
és }
Behaviour Service
FunctionalEntity =
N "nA As
.: StructuredBehaviour
MonolithicBehaviour |
N
4.
1.2 Interaction LE
causalityrelation L
wat ActivityUnit r^
i E SEE:
CausalityCondition + i
a n AS t
InteractionAlternative |
i
=
Action | M
| InteractionContribution =
fa."
I
rr] lo =
Attribute
Mtem
Information Attribute |
LocationAttribute TimeAttribute
Figure 6: A metamodel for GSI services
The abstract class behaviour defines the behaviour con-
cept, which models some type of system behaviour. A
behaviour is a (partial) description of the system that de-
scribes a distinct part of that system functionality.
An instantiation of a behaviour results in a service of value
to a user. Multiple behaviours may provide the same ser-
vice. Behaviours are associated with functional entities.
Functional entities are capable of exhibiting the charac-
teristics defined in a behaviour. A functional entity rep-
resents a logical or physical part of the system capable of
executing behaviour in the real world. A functional entity
executes behaviour by itself or in cooperation with other
functional entities. A behaviour can be carried by more
than one functional entity. A functional entity can exhibit
more than one behaviour.
Two sorts of behaviour types are distinguished: structured
behaviour, which are compositions of one or more related
smaller behaviour; and monolithic behaviour, which are
not further decomposed into smaller behaviours.
A monolithic behaviour consists of a group of related ac-
tivity units that can take the form of actions or interaction
contributions. An activity unit represents an atomic piece
of work at a given abstraction level.
An action represents an activity that is defined entirely
within a single behaviour. An interaction represents an
activity in which two or more declared behaviours partic-
ipate (cooperate). An interaction contribution represents
the participation of a behaviour in some interaction.
At higher levels in the behaviour hierarchy, the partici-
pation of one or more monolithic behaviours in some in-
teraction may be represented by the participation of the
structured behaviour in which these monolithic behaviours
are defined as sub-behaviours. This may be applied re-
cursively to structured behaviours that are defined as sub-
behaviours, such that the participation of a structured be-
haviour in some interaction may represent the participation
of monolithic and structured sub-behaviours.
Alternative groups of sub-behaviours may participate in an
interaction. Therefore, an interaction is defined as a set
of one or more interaction alternatives, where each alter-
native represents an optional group of participating sub-
behaviours.
A causality condition is associated with each activity unit.
This association is called a causality relation. A causal-
ity condition defines the type of relation between two or
more activity units. This relation is used to specify how
the occurrence or execution of activity units depends on
the occurrence or non-occurrence of other activity units.
The completion of an activity produces some result that
can be manipulated by other activities. An activity unit can
have attributes. These attributes represent the result that is
established by an activity unit.
Three attributes are defined:
e the information attribute, which represents the prod-
uct (typically some information) that has been pro-
duced by the activity unit;
e the time attribute, which represents the time moment
at which the product is available;
e the location attribute, which represents the location
where the product is available.
Items are a special class of the information attribute. Items
represent the information that is directly manipulated by
an activity unit. The type of manipulation that can be
performed on an item by an activity unit are create, use,
change or destroy the item.
The metamodel described here only allows for the defini-
tion of an abstract syntax for the design concepts used in
the creation of GSI models. The semantics of the concepts
is provided by the ISDL modelling language (citeISDL).
For further detail on the ISDL metamodel, we refer to (Quar-
tel, 2003).
REFERENCES
Ferreira Pires, L., 1994. Architectural Notes: a F ramework
for Distributed Systems Development. PhD thesis, Univer-
sity of Twente, Enschede, The Netherlands. Ph.D. Thesis,
no. 94-01.
Fielding, R. T., 2000. Architectural Styles and the De-
sign of Network-based Software Architectures. PhD the-
sis, University of California, Irvine, California.
Hadjiefthymiades, S. and Merakos, L., 2002. PoLoS: A
universal platform for the development of LBS and other
data services. In: Proceedings of the IST Cluster Meeting
for Engineering of Service Functionality, Bucharest, Hun-
gary.
Hull, R., Benedikt, M., Christophides, V. and Su, J., 2003.
E-services: A look behind the curtain. In: Proceedings
of the twenty second ACM SIGMOD-SIGACT-SIGART
symposium on principles of database systems, ACM Press.
San Diego, California, pp. 1-14.
1232
Inter
Mor
info
Ens
ITC
Mor:
2002
men!
Distr
IEEE
166.
OGC
Versi
OGC
12- €
Cons
OGC
No. C
Bueh
OMG
1.0.1,
Perry,
study
Engin
Quart:
Draft,
Arco/!
Quarte
On arc
tribute
of Inte
pp. 1—
Szyper
Object
Pub. Ci
van Sii
Protocc
The Ne
