A Study on the Design of National Spatial Data Infrastructure (NSDI)
using activity-based Domain Analysis
2.4 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
