Spatiotemporal Extensions to Unified Modeling Language Rosanne Price1, Kotagiri Ramamohanarao2, Bala Srinivasan1 Monash University, {rosanne.price, bala.srinivasan}@csse.monash.edu.au 2 Melbourne University,
[email protected]. 1. Introduction Geographic Information Systems (GIS) and other multimedia applications such as video databases have motivated recent interest in spatiotemporal data modeling. This paper presents a graphical extension to the Unified Modeling Language (UML) which is designed to support requirements analysis and specification for applications having different underlying space/time models and semantics. The term spatiotemporal data is used to refer both to temporal changes in spatial properties and changes in the value of non-spatial properties across time and space. In order to facilitate specification and design of such applications, a modeling language must at a minimum provide a clear and simple notation for both types of spatiotemporal data and at different levels of granularity, e.g. object, component, or attribute levels. A range of different semantics and models for space, time, and change processes are possible, for example: • object- versus field-based spatial models • linear versus non-linear (e.g. cyclic or branching) time models • continuous, instantaneous, or discrete (with duration) views of change (i.e. using functional-, instant-, or interval-based time representations) • multiple dimensions for space (search space and objects/fields modeled) and time (e.g. valid time, transaction-time, read time for changed data) • different interpolation semantics across time and/or space providing transformations between real-world or measured data and application semantics (e.g. discrete, step, or linear application semantics assuming that data values are undefined, static, or calculated between measured points respectively) In some cases, a single application domain may require more than one model: consider a regional health system recording changing population densities across a spatial field and the location of discrete spatial objects representing medical clinics. In one of the few papers to specifically address conceptual modeling languages for spatiotemporal
applications, [3,4] discuss extensions to an EntityRelationship (E-R) model specifically intended for conceptual modeling of spatiotemporal applications, including an in-depth discussion of spatiotemporal semantics; however, interpolation and alternate temporal models, time units, and spatial dimensions are not considered. To be generally useful, a modeling language should support a range of time and space models, dimensions, and interpolation semantics. Spatiotemporal UML (STUML) is intended to address these needs. UML is an object-oriented standard recognized by the Object Management Group. Because it includes behavioral as well as structural specifications, it represents a superset of E-R concepts and provides a more integrated analytic approach. Therefore, defining an UML extension was selected as the best approach to provide a modeling language which has a high level of acceptance, understandability, and flexibility. Representing spatiotemporal concepts using only the core constructs of UML is problematic, requiring the promotion of each spatiotemporal construct to a special class. This unnecessarily complicates the schema and reduces its clarity since there is no consistent, easily visible notation for space and time concepts. To solve these problems, a variation of the UML stereotype extension mechanism is used to incorporate spatiotemporal semantics directly in existing UML building blocks, specifically the classes, attributes, and associations of the Class diagram (describing object class structure). This is illustrated in the next section.
2. STUML Suppose we have a medical application measuring regional health statistics of different states, measured in terms of average lifespan, as related to the location, size, and surrounding population densities of hospitals. Population densities and average lifespans across states vary (measured yearly) with respect to time and district. Hospital data, state names, and district numbers are static. Figure 1 shows the application design using STUML.
HOSPITAL name: string sizeNumBeds: integer location: S operations specs Specification Box Hospital S: SpaceModel := (0,2): object
STATE name: string
G G
populationDensity: integer avgLifespan: integer
T
S
district#: integer operations specs
Specification Box State T: TimeInterpolation := step TimeModel := synch (yearly) TimeUnit := interval Specification Box State S: SpaceModel := (2,2): field
Each Spatial or Temporal symbol is associated with a corresponding Specification box which provides details of the models and interpolation semantics for each time dimension and for space. Specification box syntax is shown above in Figure 2. In this example, hospital location is a spatial attribute specified as a 0D point in 2D space. In State, the Spatial Group is used to specify that three attributes have values which vary and are measured across a 2D field. The Temporal Group indicates that historical values— measured yearly and static between measurements--are retained only for two of those three attributes. Notice the use of default values for components of the Specification Box: in this diagram, discrete spatial semantics and valid time are assumed for the spatial and temporal attributes respectively. Although not shown, the Spatial and Temporal symbols (i.e. Temporal triangle inside a Spatial circle) can be combined to indicate that a given attribute’s values vary across time and space or temporal variation of a spatial attribute. Spatial and/or Temporal symbols can also be placed at the object level to indicate that all of its attributes have the same spatial and/or temporal specifications. STUML notation is described in more detail in [1,2].
Figure 1: GIS health application using STUML
3. Conclusion
Three new symbols are introduced in Figure 1 above: • Spatial (S): the labeled attribute has a spatial domain (if there is no domain listed for the attribute) or its values (non-spatial domain specified) vary across a spatial extent, • Temporal (T): historical information should be retained for the labeled attribute (alphanumeric or spatial), class object, or association, and • Group (G): used to group attributes with common spatial, temporal, or spatiotemporal specifications. This simplifies the Class diagram and can be used to graphically illustrate sets of attributes sharing the same time and/or space specifications as described in a separate specification box.
In this paper, we have identified some basic requirements for spatiotemporal data modeling, evaluated UML with respect to these requirements, and proposed a new extension—STUML—to provide a clearer, more comprehensive and natural notation for specifying spatiotemporal data for a wide range of applications.
SPECIFICATION BOX : [TimeDim.:= [valid [,trans. [,read [,estimated [,]]]]]] [TimeInterp.[()]:=[step|min|max|avg|linear|] TimeModel [()] :=[cyclic| branch]: asynch| synch([,,]) TimeUnit [()]:=[instant| interval| period] [SpaceInterpolation:= ] SpaceModel:= ( , ):
Figure 2: Specification box
References [1] Price, R., K. Ramamohanarao, and B. Srinivasan. “Spatiotemporal Extensions to Unified Modeling Language”, Monash UniversityTechnial Report# 1997/37, April 1999, 1-10, available at www.ct.monash.edu.au/~rjprice. [2] Price, R., K. Ramamohanarao, and B. Srinivasan. “A Spatiotemporal Modeling Language For Multimedia Applications”, ISIMADE’99, in press, available at www.ct.monash.edu.au/~rjprice. [3] Tryfona, N. and C. Jensen. “Conceptual Data Modeling for Spatiotemporal Applications”, Chorochronos Technical Report CH-98-08, Sept. 1998, 1-25. [4] Tryfona, N. and C. Jensen. “A Component-Based Conceptual Model for Spatiotemporal Design”, Chorochronos Technical Report CH-98-10, Sept. 1998, 1-25.
