GISdevelopment.net ---> AARS ---> ACRS 1998 ---> GIS

A Study on the Design of National Spatial Data Infrastructure (NSDI) using activity-based Domain Analysis

Tsuneki Sakakibara and Royosuke Shibasaki
Center for spatial Information science, University of Tokyo
7-22-1, Roppongi, Minato-Ku Tokyo 106-8558, Japan
Tel & Fax L81)-3-5411-0441
E-mail: sakaki@skl-iis.u.tokyo.ac.jp

Abstract
The development and standardization of the SDI, of the SDI has been done till now, bared on the expertise of the current users and applications of GIS. But as the users of SDI and its applications will be enormous, it is very difficult to define all of them. In this sense, we can not apply the existing domain analysis & modeling approach to SDI. In this paper, we developed a new improved methodology of domain of domain analysis & modeling with emphasis on its applicability to spatial data infrastructure. We represent the concerned domains with in SDI as activities And usecases. This method allows the also analyze such targets with undefined boundaries that exist line SDI. We analyze the domain, "fire-prevention service " and "daily outdoor activity", by this method to confirm its suitability and find some issues of this method

1.Introduction
In recent year, the demand and the importance for developing the Spatial data Infrastructure (SDI) such as National Spatial Data Infrastructure ( NSDI) or Intelligent Transportation System (ITS) is increasing more and more. And with ISO undertaking the standardization of GIS and ITS (ISO/TC211 and ISO/TC204), it become even more important to also consider and include the methods to develop standards based on information Technology (IT) as part of the SDI.

At present, the architectures or standardization of SDI is mainly decided based on the conceptual models as a result of discussion with the expert member group/s. in tins kind of discussion they usually review the present uses or applications of GIS at first and and based on their personal experiences, they define the data requirements or conceptual models for SDI and its standardization. This means that they have no sufficient methods or theories to broaden thearchitecture or conceptual models ot include other uses or applications. To develop the NSDI, however, it takes h huge public investment and quitte a ong time. This kind of ivestments need to provide a clear answer to questions such as "why such investment is needed to develop SDI:, " how much social benefit deoes the SDI provide ?," how much demand arise for the SDI?", or "why some data is relatively more important than other in the SDI?". This creates a strong demand to develop methods or theories to answer these questions systematically and reasonably. But it is not so easy to meet this demand just by accumulating and reasonably. Nit is this not so easy to meet this demand just by accumulating opinions of experts in an advantageous manner.

In this study, we aim to develop a new improved methodology of domain analysis that will also development of the design architecture of SDI systematically and reasonably, by so taking into account potential uses and/or applications. And using this method we will experimentally design he data architecture of NSDI. Through this process, the validity and issues of this method will be made clear.

2.activity-based Domain Analysis

2.1 Existing domain analysis method
At present, in developing some software or computer system, the system requirements are comprehended systematically and represented by was of model that are made by so-called domain analysis & modeling. Domain analysis & modeling is a method that analyzes target operations or services and expresses the information processing methods as rule in the model. A target of tins method is an operation or service that can be found to have operational patterns and are relatively easy to develop those patterns as a system like in a cash Dispenser system.

The modeling method is composed of two domains one is a question domain consisting of common characteristics or attributes. Another is an application domain containing systematic solutions. The question domain is developed mainly in two ways-one, is based on the interview of experts of the target by domain analysts; two; by referring to some of the documents describing the operational rules of the target system. A question domain makes clear the operations that the system must support, and, at the same time, defines the operations that the developed system cab handle. After defining a question domain, we now define an application domain in detail.

This part of domain analysis & modeling describes the user's present behavior and is represented as a usecase. And analyzing each usecase, we extract data items or functions as a class. Therefore when we use this existing method, targets ought to satisfy the following conditions.
  1. in a target, user behaviors have to be relatively patterned. This helps to clarify its boundary like fewer users in the domain or simplifying actions in the question domain based on this.
  2. In a target, user's actions are relatively steady in future too, so there is no need to consider future changes of such actions. This means, even if IT progresses, behaviors themselves are relatively stable. So data requirements or system functions cab be defined based on present behavior.
2.2 Characteristics of the SDI
The major characteristics of the SDI are as follows
  1. The major span of SDI is quite long. And considering that present behaviors are based on present technologies or social- and economical-situation, they will change with the progress of them. So designing SDI, it is required to consider not only actual behaviors but also potential at present situation.
  2. Therefore, developing a framework of SDI is required long-tem stability, future possibility f expansion and graded expansion. In case of arising new user needs, the easy-expansion of developed SDI is required. In the actual developing sage, SDI is required be able to work itself if develop from high priority data having more needs or tangible
  3. There is few used using SDI directly and with out the other informationSDI having developed, it will be provided the services processing some information in SDI and data from the other sources together in this sense, it is said SDI is a middle-ware-typed infrastructure.
  4. Considering above, the usage and user of SDI will be quite various. So it is very difficult to detect what kind of usage is expected or who uses.
  5. SDI will be developed by the investment of public fund. Therefore it is required anticipating the effect an social impact of developing it. Especially, it is required the method it anticipate how private companies' or individuals ' behaviors change or how their convenience or comfort goes up through the SDI on the design step.
2.3. Basic ideas of the new improved methodology of domain analysis & modeling The existing models are insufficient to address some of the above major characteristics of SDI. In this study, we suggest a new improved methodology of DOMAIN analysis & modeling the basic ideas of such an approach are listed follows:
  1. Domain and activity
    • A target DOMAIN consists of a set/s of activities. An activity is a process in which the subject choose the best possible alternative form a set of alternatives for achieving an objective an activity itself has some possibility of change with the progress of IT. But in the method, we concentrate our attention on a set of decisions to achieve some objectives rather than a set actions. So the result of analysis will be relatively stable.
    • An activity consists of a set of sub-activities Considering the sub-activities as a part of choices to achieve the objectives of the activity, we represent the relationship between activities and sub-activities hierarchically. Thus we can stop p at the first step of analysis when the detailed ness of sub-ACTI meets the requirement of the analysis by tis method the relationship of various DOMAINs and activities (including sub-activities )can be represented in a relatively simple manner. A sub-activities contains dat about relationship with other activities, data transfer plans among itself and concerned activity, physical and spatial attributes of actors, and so on.
    • after developing a set of relevant activities and sub-activities for the DOMAIN, we cab the group of the act, except the DOMAIN-top-activity, into two categories. One is a group of informational activities that are mainly involved in collecting and processing necessary data, decision making and passing some information. Another set consitst of physical and spatial activity such as moving, consuming and producing something.
  2. actor An actor is subject of an activity. In other words, an actor is one who is -an intermediate decision-maker (at the level of a certain activity or sub-activity )or the final decision maker. An actor is not only human being but also activities is the other DOMAINs.
  3. Use Case and super-Usecase
    • A usecase is defined as the set of conditions or cases that executes itself in unison. So, a usecase is contemporary to a sub-activity or t a CLASS. Since, a usecase is an executable case consisting of a set of actions, it can be dealt with by the existing domain analysis modeling methods. So if needed, a usecase can be analyzed by them in detail and developed as a sub-system.
    • In usecases, we proceed analyzing human behavior from an operational task level to each action level described by the respective conditions ( or cases ). It satisfies, in a bottom-up approach. we aggregate all those usecases that can implicitly explain each other, which were term super-usecase. So, super-usecases are disjoint sets, in nature. When choosing e best possible architecture for the SDI, the super -usecase with the most possible usecases gives the highest possible operational options for such a system
2.3 The procedure of activity-Based Domain Analysis
Considering the above points, we call this new domain analysis method "activity-based Domain Analysis (ADA) ". The overall procedure can be explained as follows-at first =, we define the domains that ought to be incl8uded in SDI. We extract needed activities form all the domains and divide then into the lowest possible sub-activities. Then based on the conditions ( or cases ) of executing the sub-activity, we derived the required usecase Getting all the usecase within the given domain, we aggregate some of the usecases into super -usecases in this aggregation, each usecase is part of one super usecase. As a result of this, we cab count the number of usecases aggregated by super -usecase. And this number can be used as an evaluation criterion of importance of super -usecases. By finding more important super usecases and by following certaitn criteria, we can design the data architecture in detail taking the priority account.

This method also allows us to connect existing behavior analysis modeling methods seamlessly and to work with evaluation methods of public investments effectively. In terms of physical and spatial activities, we expect to combine some other methods that can deal with spatial behavior such s quantitative models like travel demand forecasting Also, its si expected that we can estimate the effect of developing SDI quantitatively, by evaluating the changes in human behavior and the effect of the resulting changes in procedure s to achieve in the objective of an activity based on any new information services.

3. An Example of activity-based Domain Analysis
We analyze the domain, " fire-prevention service " and " daily outdoor activity ", by ADA to confirm the suitability and find the advantages & disadvantage of this method. And thorough this example. We aim to develop the architecture of NSDI finally ( the first step in developing such a system ).

In figure 1 there are domains and activities that are dealt with in this example. After extracting activities from all the domains, we extract sub-activities by time series procedure of an activity. And as written before, these sub-activities are called usecases in this example figure 2 shows the usecases of one activity each in the two DOMAINs, of fire -prevention service and daily outdoor activity. One set is extracted form "fire"-activity, "fire -prevention service"-DOMAIN and another is "shopping ", daily outdoor activity ". As we find form a figure 2, a usecase does not exists independently but sends and gets some information with other usecases.

Domain
1) fire -prevention service, 2) Daily activity
Activity
Fire -prevention service daily activity
  i) fire   i) shopping
  ii) rescue   ii) work
  iii) medical emergency   iii) trip/sightseeing
    iv) having a close relationship
  with friends

Figure 1 Activities in the Domain of fire-prevebtion service and daily activity



Figure 2 usecases extracting from "fire, fire -prevention service " and "shopping, usual behavior "



Figure 3. Hierarchical representation of part of informational requirement of NSDI

Here each usecase is also an actor

At first next step we classify these usecases in terms if its conditions ( or cases ) "objectives of task", "alternatives of mode, means, etc. or "constraints ". The result is shown in figure 3.

In this method, there is a to of decision-making, aggregation or classification. So if they do not have an unified criteria, it is very difficult to find the same level activities or usecases of abstraction if the weight ages attached to the various sub-activities are non-uniform, then the number of aggregated usecases cab not be used as an impotence index of a super -usecase.. even, if we apply an uniform weight age to all the sub-activities, with out explicitly identifying the criteria of extracting the usecases from the sub-activity, this may lead to an undesirable increase in usecases. For example, when dealing with a round trip, the number of aggregation may be different depending on whether going and coming back in counted separately as two different usecase or as one.

4. Conclusion
In this paper, we could develop the framework of the method of activity based Domain Analysis This method can handle the Domains both that have not been analyzed or are difficult to systemize and those that can be systemized by existing domain analysis methods Through the analysis of the above example, we discover 3 issues that need to be focused on first, it is needed to develop a method to represent the relationships among usecases second, there is a need to develop a unified criteria for creating super -usecases This enables to deep the levels for abstraction of super-usecases at the same level. Third, it sis also needed to develop an unified method to extract usecases from a activity this enables to arrives at uniform weight ages for the usecases.

The activity -based Domain Analysis enables to design the architecture of SDI systematically and reasonably by improving these issues it is important tat we not only develop the SDI but also maintain it with the latest information in this sense, we need to formulate the methodology designing for the maintenance program, including issues like "who makes a datum" or "who and when to revise data " from now on, in addition to improving ADA.

Reference
  • Ivan Somerville, Richard Bentley, Tom Rodden and Peter Sewyer : Cooperative Systems d Design, The Computer Journal, 37,5,pp.357-366, 1994
  • Yshio Arai, Kohei Okamoto: Space and Time in Urban City (in Japanese 1996)
  • Tomoyasu Suzie: a new approach to ravel research based on activities (in Jpapnese), Traffic Engineering, 19,2,pp.19-27, 1984
  • Minoru Nakajima: Bias in Human Reasoning, 1995.
  • Toshiki Tomino: A Basic of Requirement Define Engineering (in Japanese ), 1997
  • Shin-ichi Honiden: Modeling the world with Objective (in Japanese), 1995
  • Kiyoshi ITO, Yasuhisa Tamura: Domain Analysis & Modeling (in Japanese), 1996