Open source geo-web services for mobile data capture in cadastral applications

SERVICES FOR MOBILE DATA CAPTURE IN CADASTRAL APPLICATIONS

ERVIN RAMONLLARI February, 2011

SUPERVISORS:

B. J. K¨obben MSc

Dr. J. M. Morales

SERVICES FOR MOBILE DATA CAPTURE IN CADASTRAL APPLICATIONS

ERVIN RAMONLLARI

Enschede, The Netherlands, February, 2011

Thesis submitted to the Faculty of Geo-information Science and Earth Observation of the University of Twente in partial fulfilment of the requirements for the degree of Master of Science in Geo-information Science and Earth Observation .

Specialization: Geoinformatics

SUPERVISORS:

B. J. K¨obben MSc Dr. J. M. Morales

THESIS ASSESSMENT BOARD:

Dr.Ir. R. A. de By (chair)

Ir. C. H. J. Lemmen

Observation of the University of Twente. All views and opinions expressed therein remain the sole responsibility of the author, and

do not necessarily represent those of the Faculty.

Nowadays mobile devices equipped with GPS receivers are being used worldwide for field data collection. Cadastre information systems can benefit from using mobile device technology where both spatial and non-spatial data can be collected in the field. However, the mobile devices suf- fer from technological limitations such as small screen size, small memory and processing power, and furthermore they use wireless networks for communication which are unreliable and costly compared to wired networks. Therefore, the design of a mobile data collection system requires special attention. In this research we designed a mobile system for cadastral data collection which contains two components, a mobile device and an SDI node for mobile client – SDImobile com- ponent. The mobile device is used to capture cadastral data while SDImobile handles the commu- nication of the mobile device with other SDI nodes which offer resources (data/services). Further- more, SDImobile processes the input data from the mobile device and sends them into the cadastre SDI node. Although the design is based on a cadastre use case, this research aimed at designing a generic and interoperable SDI node. For the purpose, we used service orientation paradigm to de- sign reusable and generic web services for the SDI node. By using open web standards we aimed at designing an interoperable SDI node. A proof-of-concept prototype was implemented and tested, using free and open source software. We believe that the use of a mobile device, supported by a generic and interoperable SDI node, is very promising and offers great potential for field data collection applications.

Keywords

mobile device, SDI node, generic, interoperability, open standards, cadastre

Abstract i

Acknowledgements vii

1 Introduction 1

1.1 Motivation and problem statement . . . . 1

1.2 Research identification . . . . 2

1.2.1 Research objectives . . . . 2

1.2.2 Research questions . . . . 2

1.2.3 Innovation aimed at . . . . 2

1.2.4 Related work . . . . 3

1.3 Project set-up . . . . 4

1.3.1 Method adopted . . . . 4

1.4 Thesis outline . . . . 4

2 User requirements for cadastral data collection 7 2.1 Introduction . . . . 7

2.2 Cadastre concepts . . . . 7

2.3 Cadastre systems in different countries . . . . 8

2.4 Use scenario . . . . 10

2.5 Non-functional requirements . . . . 11

2.5.1 Business constraints . . . . 11

2.5.2 Quality attributes . . . . 12

2.5.3 Technical constraints . . . . 13

2.5.4 Accuracy constraints . . . . 13

2.6 Summary . . . . 13

3 Analyzing requirements for cadastre data collection 15 3.1 Introduction . . . . 15

3.2 Modeling and designing approaches . . . . 15

3.2.1 Development approaches . . . . 15

3.2.2 The Unified Modeling Language . . . . 17

3.3 Analyzing user requirements . . . . 18

3.3.1 System in context . . . . 18

3.3.2 Defining use cases . . . . 18

3.3.3 Defining system architecture . . . . 21

3.3.4 Domain model . . . . 23

3.4 Designing the system . . . . 24

3.4.1 Sequence Diagram . . . . 26

3.4.2 Class Diagram . . . . 29

3.5 Summary . . . . 31

4.1 Introduction . . . . 33

4.2 SDImobile’s role . . . . 33

4.3 Analysis and Design . . . . 34

4.3.1 Service orientation . . . . 35

4.3.2 Service-orientation design principles . . . . 36

4.3.3 Analysis . . . . 37

4.3.4 Design . . . . 42

4.4 Summary . . . . 46

5 Prototype implementation and testing 47 5.1 Introduction . . . . 47

5.2 Technology and tools for implementing mobile device client . . . . 47

5.3 Technology and tools for implementing SDImobile node . . . . 48

5.4 Prototype implementation and testing . . . . 48

5.4.1 Mobile client implementation . . . . 49

5.4.2 SDImobile implementation . . . . 50

5.4.3 Prototype testing . . . . 51

5.5 Summary . . . . 53

6 Discussion, conclusions and future recommendations 55 6.1 Discussion on research questions . . . . 55

6.2 Conclusions . . . . 58

6.3 Recommendations for future work . . . . 58

Bibliography 61 A Web Service design 67 A.1 Schema definitions . . . . 67

A.2 Interface definitions . . . . 72

B Prototype implementation 83 B.1 Mobile client GUI . . . . 83

B.2 SDImobile implementation . . . . 86

B.2.1 OGC Web Services . . . . 86

B.2.2 SDImobile functionality . . . . 88

2.1 Field survey scenario . . . . 12

3.1 Mobile Data Collection System, Context Diagram . . . . 19

3.2 Survey Parcel Use Case Diagram . . . . 21

3.3 Activity Diagram . . . . 23

3.4 Mobile Data Collection System, Logical Architecture . . . . 24

3.5 Activity Diagram Refined to Include SDImobile Component . . . . 26

3.6 Domain Model, representing the conceptual classes in the problem domain . . . 27

3.7 Sequence Diagram showing the sequence of messages between objects . . . . 28

3.8 Class Diagram showing the design classes, their attributes, methods, and relation- ships . . . . 30

4.1 SDI node stack . . . . 34

4.2 Service Candidates . . . . 41

4.3 Service Composition Representing Cadastral Survey Process . . . . 41

4.4 Conceptual view of the service composition process in WS-BPEL . . . . 45

5.1 Measured points with Mobile Client . . . . 52

3.1 Survey Parcel use case . . . . 19

4.1 Cadastral Property XML Schema . . . . 43

5.1 WFS-T Request Content . . . . 50

A.1 Property Schema . . . . 67

A.2 Address Schema . . . . 69

A.3 Person Schema . . . . 70

A.4 Utility Schema . . . . 70

A.5 Surveyor Schema . . . . 71

A.6 User Schema . . . . 71

A.7 ProcessFeature Service . . . . 72

A.8 CadastralProperty Service . . . . 75

A.9 UserSession Service . . . . 76

A.10 SearchResources Service . . . . 78

A.11 CadastralSurvey Composite Service . . . . 79

B.1 Mobile client GUI . . . . 83

B.2 Web Feature Service configuration, Utility Lines . . . . 86

B.3 Web Map Service configuration, Cadastral Parcels . . . . 87

B.4 SDImobile functionality implementation - ASP/Python . . . . 88

This research thesis is the final result of my studies in Geoinformatics at the Faculty of Geo- information Science and Earth Observation (ITC) of the University of Twente. I would like to express my sincere gratitude to ITC and NUFFIC for giving me the opportunity to follow this Master of Science course. A special thank to ITC staff for creating such a warm environment and making the studies easier.

Special thanks to my first supervisor, MSc. Barend Köbben, for sharing his enthusiasm and patiently guiding me throughout the research period. I would like to thank my second supervisor, Dr. Javier Morales, for discussing and sharing his ideas with me. Another person I would like to thank is Dr. Rolf de By for his useful pep talks and for making the thesis writing much easier.

This study period has been tough and intensive. The presence of my ITC friends has made it easier for me and definitely a more enjoyable experience. I would like to thank here all my GFM classmates and other ITC fellows.

Finally, I would like to thank my family for the support and encouragement: my parents, my grandmother, and my brother and his wife. Especially, I would like to thank my wife:

– thank you my darling for being always there for me! –

Chapter 1

Introduction

1.1 MOTIVATION AND PROBLEM STATEMENT

The development of Information Technology (IT) has influenced the evolvement of GIS technol- ogy from traditional GIS towards distributed GIS, part of which is mobile GIS (Peng and Tsou, 2003). The emergence of Mobile GIS brought new ways of geospatial data collection, processing, maintenance and dissemination (Mensah-Okantey, 2007). Nowadays, mobile GIS is being widely used in field data collection, both in governmental and private enterprises. Cadastral application is one of the fields that can benefit from mobile GIS especially in developing countries where there are technical and financial difficulties in creating digital cadastral data acquisition systems (Mensah-Okantey and Köbben, 2008).

Land administration and cadastral systems are the foundation of the economic growth of many countries as they register the information on land. A cadastre system involves cadastral mapping (the spatial information) and land registration (the non-spatial information) (Lemmen and van Oosterom, 2004). While in developed countries information technology has been used in cadastral systems during the last 2 decades, in developing countries, although there is need for such technology, there are financial and operational restrictions (Steudler et al., 2010).

Cadastral data acquisition requires field work and as such it is labour intensive, time con- suming and expensive. Existing methods of cadastral data capture are used to collect spatial and attribute data separately in the field. Spatial cadastral data are collected using traditional methods like total stations, GPS, aerial photography, or other field measurements. On the other hand, the attribute data are recorded manually, using paper and pen. Later, both spatial and attribute data are processed and integrated in the cadastral office and then loaded into a database. But, this approach is time consuming, prone to errors and requires careful processing of gathered data.

As the GPS, internet, and wireless communication technology is evolving, mobile GIS offers good possibilities for spatial and non-spatial data collection in the field (Peng and Tsou, 2003).

In this respect, mobile GIS has the potential to facilitate cadastral data collection by integrating spatial and attribute data collection directly in the field. Further, as stated by Pundt (2002), mo- bile GIS tools can be designed in such a way that they can control the quality of captured data in the field. However, as any other technology, mobile GIS has few technological limitations.

Such limitations are related to communication network, low bandwidth (Farkas et al., 2006), and mobile device limitations such as small screen size and processing resources (Biuk-Aghai, 2004;

Casademont et al., 2004; Wilson et al., 2010). Despite these technological limitations, the mobile technology is widely used in location-based services (LBS) like real-time traffic information, rout- ing, finding the nearest attraction locations, and mobile GIS applications for communication and facility management (Peng and Tsou, 2003).

An example of mobile GIS implementation in cadastral data collection is given by Mensah-

Okantey (2007) who developed a prototype mobile GIS application for cadastral data collection

in Ghana. However, the mobile prototype has its own limitations. Firstly, it is built using propri-

etary software and is platform-dependent (the mobile client application runs on mobile devices

equipped with Windows CE operating system), which means there are some license costs related to it. Nowadays, more and more countries are implementing and developing their own SDIs, which employ open standards and OGC-compatible geo-web services to ensure interoperability.

Unfortunately, the prototype was not based on open standards and OGC services and interfaces, and as such it lacks the interoperability with other SDIs. Secondly, the research was more focused on the cadastral processes in Ghana. Thus the prototype was built to support the cadastral data acquisition in Ghana and offers no possibility for use in other countries.

1.2 RESEARCH IDENTIFICATION

1.2.1 Research objectives

The main objective of this research is to design a generic Spatial Data Infrastructure (SDI) node which offers services that facilitate mobile data collection in a cadastral context. From the main objective of the research the following sub-objectives are derived:

• To study the user requirements for a cadastre data collection system;

• To design a generic SDI node following the user requirements;

• To study the existing free and open source technology that can be used to implement a prototype of the system;

• To build an interoperable and OGC-compliant prototype of the system, using the appro- priate technology;

• To test the functionality of the system’s prototype.

The group of users that can benefit from the proposed system are the field surveyors who collect cadastral data and other interested actors in cadastral organizations.

1.2.2 Research questions

The following research questions are posed to guide this research and meet the objectives:

1. What are the user requirements for a cadastral data collection system?

2. What methods and techniques can be used to design a generic system that satisfies the user’s requirements?

3. Which free and open source technologies and tools can be used to build an interoperable, OGC-compliant prototype of the mobile system?

4. How to combine different technologies and tools to build a prototype of the system?

5. Does the prototype contain the required functionality for a cadastral application?

1.2.3 Innovation aimed at

This research aims at designing an interoperable and platform-independent SDI node, that offers

generic functionality for facilitating mobile cadastral data capture. The generic nature of the

SDI node and its interoperability with other SDIs is achieved by using OGC-compliant geo-web

services and open standards. Moreover, free and open source software (FOSS) are used to build a

prototype of the SDI node, which also includes a mobile device client.

1.2.4 Related work

The use of mobile GIS for field data collection has attracted many researchers. Casademont et al.

(2004) present an overview of the wireless technology — mobile devices and wireless networks

— and positioning technology — GPS and differential GPS — that can be used in GIS. The authors also give an example of a wireless GIS platform (client and server components) created by integrating the reviewed technology.

Hall and Gray (2004) developed a mobile system for field data collection with the main objec- tive to facilitate collaboration and coordination of surveyors in large field surveys. CoMPASS is another mobile GIS application that offers the user GIS functionality such as navigation, spatial querying and manipulation of vector-based spatial data (Doyle et al., 2010). The authors were particularly concerned with the interaction methods between the user and the mobile device.

For that purpose they developed a multimodal interface for the mobile client and evaluated its efficiency. Wagtendonk et al. (2004) developed a mobile GIS application for assisting the field sur- veyors in mapping crops in The Netherlands. The mobile application was built using proprietary software (ESRI’s ArcPad).

Other researches are focused on the formats that can be used to display data in mobile GIS ap- plications. An example is MacauMap map application intended for tourism purposes (Biuk-Aghai, 2004). The main concern of its design was the format used for map display in mobile devices with constraint resources such as limited memory and processing power. As a result the author proposed a custom data format for use in the MacauMap application. Brinkhoff and Weitkämper (2005) studied the XML-based, Scalable Vector Graphics (SVG) format for representation of vec- tor data in maps. SVG format is complex and contains features that are not needed for GIS data, but on the other side, it is lacking some features needed in GIS. Therefore, the authors propose a format that is a restriction/extension of the SVG, which can fulfill GIS requirements for vector data representation in Location-Based Services (LBS). In this context, another research proposes a format conversion algorithm which can be used to reduce the size of the map, making it more suitable for use in mobile devices (Kim et al., 2004). Shi et al. (2009) have designed and tested a dynamic data model for mobile GIS. This data model was implemented into a database which provided up to date information, relevant to the position of the mobile device. According to the authors, the response time of the dynamic database was reduced to one-third as compared with a conventional database.

MAPPER (MAP PERsonalization) is a prototype GIS that implements an approach of pro- viding personalized information to the user (Wilson et al., 2010). Basically, it monitors the user interaction with the map, and based on the gathered information, provides only the necessary information to the user. According to the authors, this approach avoids information overload and increases efficiency of interactive map applications.

Another research shows the possibilities of integrating Spatial Data Infrastructures (SDIs) and mobile technology for disaster management (Brinkhoff, 2008). In this research a three-tier archi- tecture was developed. The architecture’s components provide personalized map contents based on the mobile device characteristics, the user profile, and the current location.

Shea and Cao (2010) have developed a software foundation package as a set of pre-compiled dynamic link libraries (DLLs) that can be used for developing GIS applications on mobile devices.

To create the package, named libMobileGIS, the authors have used only free and open source softwares, but it is only intended for mobile devices that run on Microsoft Windows operating systems.

A prototype mobile application was created by Mensah-Okantey (2007) to support the cadas-

tral data collection in Ghana. However, more effort was put on modelling the cadastral processes

in Ghana and a proof-of-concept prototype was created using proprietary software.

The proposed mobile system is also intended to support cadastral data collection, but the aim is to create a generic and interoperable SDI node using OGC-compliant services and interfaces.

In this research project, a prototype of the system is created using free and open source software.

1.3 PROJECT SET-UP

The research questions raised above require adequate answers. The approach and methods that were adopted during this research for answering the research questions are described below.

1.3.1 Method adopted

The approach that guided this research considered the sequence of the questions in chronological order. First of all literature was studied for gathering and analyzing the user requirements for a cadastral data collection system. During that phase the requirements for the server, services and mobile client were gathered. Those user requirements were then used to model the system.

From the modeling techniques and tools that were found in the literature, like object-oriented and formal methods (Hull et al., 2005), the most appropriate ones for modeling the proposed system were selected. After modeling the system, we implemented a proof-of-concept proto- type. Available free and open source technology and tools, like OpenLayers library (http://

www.openlayers.org/) and gvSIG Mobile (http://www.gvsig.org/web/home/projects/

gvsig-mobile ), that could be used to build the mobile system were considered. One of the design requirements for the proposed SDI node is that it should be interoperable and OGC-compliant.

From this perspective, the focus during the implementation phase was put on the technology that enables creating an SDI node that can communicate and consume OGC-compliant geo-web ser- vices. The selected tools and technology were then used to create the prototype of the mobile system, containing server-side functionality and a client for the mobile device.

The steps of the research described above were sequential as they logically followed each other, while trying to answer the questions (1) to (4). On the other hand, the system evaluation was run throughout the system design in order to ensure that the system followed the user requirements.

The evaluation also continued during the system implementation phase. The purpose was to test the developed functionality of the prototype and make improvements where needed. At the end of the prototype implementation phase, a final evaluation was performed for testing the prototype as a whole (earlier its functionalities were tested in isolation).

1.4 THESIS OUTLINE

The research conducted during this thesis is structured into 6 chapters, as described below:

Chapter 1 – Introduction gives an outline of this research, including the motivation and objec- tives, the underlying research questions, related work, and the methodology adapted.

Chapter 2 – User requirements for cadastral data collection describes the user requirements for cadastral data collection. Literature on experiences from different countries was studied and a use case scenario was created. This use case scenario was adopted in the context of using a mobile device for field data collection.

Chapter 3 – Analyzing requirements for cadastre data collection analyses the user require-

ments for field data collection. The literature was studied and appropriate methods were

used to analyze the user requirements and design the concept of the system.

Chapter 4 – SDI node for mobile client – SDImobile presents the analysis and design of the SDI node for mobile clients. Again, literature was studied to find the proper technology and standards for designing generic and interoperable web services as part of the SDI node.

Chapter 5 – Prototype implementation and testing describes the implementation of a proof- of-concept prototype. We have used free and open source software to implement some of the SDImobile functions as well as a graphical user interface for the mobile client. At the end we tested the prototype functionality by simulating a field survey.

Chapter 6 – Discussion, conclusions and future recommendations draws the results of this research. The results of the research are discussed in relation to the research objectives.

Conclusions of the research are drawn in here, and some recommendations for future im-

provements are made.

Chapter 2

User requirements for cadastral data collection

2.1 INTRODUCTION

This chapter describes the user requirements, in terms of functionality, for a field cadastral data collection scenario, using a mobile device. Experience from different countries in cadastral data collection is gathered and analyzed from which the functionality of the system will be derived.

The system will not be tailored to a cadastre in a particular country because the aim is to create a generic system that can work in different countries with different cadastral systems.

Before starting to model and implement the system there is need for user requirements. The user requirements are the basis of a system as they define what the users want the system to do in order to fulfill their needs (Hull et al., 2005), rather than how to do it (Liu, 2002). The approach followed in this research for collecting user requirements considers a use scenario. Use scenarios can be created by discussing with the users and are considered a very good way of modelling what users do or want to be able to do (Hull et al., 2005). Due to time constrains the use scenario will not be built by discussing with the potential users. Instead, literature is studied and cadastral systems of different countries are analyzed and a use scenario is created. Following such approach allows to create a generic system for field data collection, which can be used in different cadastral systems.

2.2 CADASTRE CONCEPTS

Before creating the use scenario it is relevant to give some definitions of main concepts of the cadastre. Many definitions exist since each country has implemented its own cadastre, often quite different from the others.

Henssen (1995) defines cadastre as:

“a methodically arranged public inventory of data concerning properties within a certain country or district, based on a survey of their boundaries. Such properties are systematically identified by means of some separate designation. The outlines of the property and the parcel identifier normally are shown on large-scale maps which, together with registers, may show for each separate property the nature, size, value and legal rights associated with the parcel. It gives an answer to the question where and how much.”

Henssen’s definition is extended by Kaufmann and Steudler (1998) in their vision for Cadastre 2014, to include public and traditional law aspects of cadastre:

“Cadastre 2014 is a methodically arranged public inventory of data concerning all

legal land objects in a certain country or district, based on a survey of their bound-

aries. Such legal land objects are systematically identified by means of some separate

designation. They are defined either by private or by public law. The outlines of the

property, the identifier together with descriptive data, may show for each separate

land object the nature, size, value and legal rights or restrictions associated with the land object”.

In this definition, the authors introduce the registration of the legal aspects of the land or the rights on land, which is known as the land registration process (Henssen, 1995; UN/ECE, 1996).

The United Nations Economic Commission for Europe in its guidelines for land administra- tion (UN/ECE, 1996), describes cadastre as “an information system consisting of two parts: a series of maps or plans showing the size and location of all land parcels together with text records that describe the attributes of the land”.

An extended definition on cadastre, which includes also the land registration process and the purposes the cadastre can serve, is given by the International Federation of Surveyors (FIG). In- ternational Federation of Surveyors (1995) describes the cadastre as:

“a parcel based, and up-to-date land information system containing a record of interests in land (e.g., rights, restrictions and responsibilities). It usually includes a geometric description of land parcels linked to other records describing the nature of the interests, the ownership or control of those interests, and often the value of the parcel and its improvements. It may be established for fiscal purposes (e.g., valuation and equitable taxation), legal purposes (conveyancing), to assist in the management of land and land use (e.g., for planning and other administrative purposes), and enables sustainable development and environmental protection”.

If we make an attempt to summarize from the above definitions, we may simply define the cadastre as an information system that records spatial and non-spatial information on land. From those definitions it is obvious that at the core of a cadastre is the land. A legal perspective of land is given by UN/ECE (1996) which describes land as “the volume of space that encompasses the surface of the Earth, all things that are attached to it, and the rocks and minerals that are just below it. Land includes areas covered by water such as seas and lakes, all building and construction, and all natural vegetation”. In this research we will use the concept of land parcel which is defined by Henssen (1995) as “a continuous area of land within which unique and homogeneous interests are recognized”.

2.3 CADASTRE SYSTEMS IN DIFFERENT COUNTRIES

In this section we give an overview of the cadastral systems in five European countries, namely Austria, Bulgaria, Croatia, Hungary, and The Netherlands, based on a publication of the Center of Legal Competence (CLC, 2009). We also shortly describe the cadastral situation in Ghana and Albania.

The history of cadastre is different in different countries. In Austria it was introduced in 1817 as a cadastre for taxation purposes and by 1861 entire country was surveyed; but the land registration concept dates back in 12 ^th century when the property transfers and mortgages were recorded in a public book (Sadjadi, 2009a). Nowadays, in Austria, there is an up-to-dated land information system which contains the Land Book, for recording the real properties and their rights, and Cadastre, for recording technical data on parcels and buildings, such as boundaries and parcel identifier (Sadjadi, 2009a). Since the cadastre data covers the entire country, the land survey is done when requested by the owner for the reason of property conveyancing, determination of exact boundaries for personal reasons, or in case of property subdivision (Sadjadi, 2009a).

The situation is slightly different in Bulgaria which did not have a cadastre or land registration

until the beginning of 1900 (Petrova, 2009). In 2001 the Cadastre and Property Register Act came

in force which regulates the activity of cadastre and property register (Petrova, 2009). Accord- ing to Petrova (2009), cadastre contains the identification number, boundaries, area and building information of the immovable properties, while the property register contains the deeds, which are documents used for transferring the ownership or any other legal right on land. The cadastre data does not cover entire country, thus the field survey is carried out to measure new property boundaries or to split/merge exiting ones after the request of the owners (Petrova, 2009).

In Croatia the land registration system was started in 1855 by the Croatian Land Registration Order (Josipovi´c, 2009). During the time many changes have happened in the Land Registration in Croatia, until the recent situation, where the cadastre and land registration are handled by two institutions (Josipovi´c, 2009). The cadastre contains information on parcels, buildings, the area of parcel, the usage, etc., while the land register contains information about the owner, real encumbrances, construction rights, etc. (Josipovi´c, 2009). Josipovi´c (2009) states that the main problem in Croatian land administration system is that it does not reflect the real situation of cadastral data and the rights on land. The field survey is initiated by interested private or public actors and is carried out by private licensed surveyors (Josipovi´c, 2009).

In Hungary, what started in 1875 as cadastre with two parts, cadastre register and cadas- tre maps, is now integrated into a Unified Land Register System and stored in a computerized database (Sadjadi, 2009b). The cadastral component of the Unified Land Register System contains the parcel boundaries, parcel number, buildings and other constructions on the parcel, etc; the legal component contains: descriptive information on the parcel such as parcel number, address, area, status of the property, etc; ownership information such as owners name, address, etc; and encumbrances such as mortgages, servitudes, etc. (Sadjadi, 2009b). The field surveying is done by private licensed surveyors to partition the properties, demarcate the boundaries, etc., upon request of the owners. The cadastre in Hungary covers the entire country (Sadjadi, 2009b).

In the Netherlands, the cadastre was first introduced in 1810 for fiscal purposes, and by 1832 the entire country was covered (van der Molen, 2009). Today, there is one combined land registry and cadastre which covers the lands and territorial waters of the Netherlands, owned by the state or the private owners (van der Molen, 2009). According to van der Molen (2009), it registers the owners’ information, like name, address, civil status, etc., and spatial information on parcels like boundaries, parcel identification number, buildings, etc. Similar to Bulgaria, in the Netherlands, the so called public registers are used for registering the notarial deeds (van der Molen, 2009).

A field survey is done by the cadastral agency’s employees to measure the boundaries of divided land parcels or for reconstructing the exiting boundaries, upon request of the land owners (van der Molen, 2009).

In Ghana, the land registration is regulated by two laws since 1957 (Mensah-Okantey, 2007).

Actually, the land registration in Ghana does not cover entire country, and sporadic surveys are carried out to register the parcels and rights. Different survey methods, like GPS, total station and aerial photography, are being used to survey parcel boundaries. Licensed private surveyors and cadastral organization’s surveyors are employed for surveying the cadastral parcels (Mensah- Okantey, 2007).

In Albania, the history of the cadastre is relatively new. Before 1990s the land was owned by

the government. In 1991, with the creation of the new Land Law, the land was distributed to

private owners (Jazoj et al., 1997). In this situation, it became necessary to develop the cadastral

system that would register documents from different organizations such as rural cadastre, forest

and pasture cadastre and so on (Jazoj et al., 1997). In the core of the new system was the cadastral

map which showed the property parcel (Jazoj et al., 1997). For the areas of the country where

the cadastral maps did not exists, it was planned to use aerial photography and other field survey

methods like tachymetry (using theodolites and total stations) (Jazoj et al., 1997). Two methods

are being used for registering the information on land: sporadic registration – registration of the land parcel and ownership when the owner decides to transfer (sell, mortgage, etc); and systematic registration – a systematic registration of the land parcels and rights for a defined area called Cadastral Zone (Stanfield, 2004). Nowadays, there are ongoing attempts to create a digital cadastre for storing and managing the land information of the entire country.

2.4 USE SCENARIO

In many countries, cadastral field survey is carried out by expert surveyors, being them private licensed surveyors or cadastral organization’s employees. The main reasons for conducting a field survey are to delineate the boundaries of the properties, thus creating land parcels, or subdivi- sion/merge of existing land parcels. The latter situation is common in countries that have a cadastre that covers the whole country. The former is found in countries where cadastre is not consolidated yet. Other reasons for conducting a field survey are the resolution of the bound- ary disputes, redefinition of the boundaries in case of boundary loss, remeasuring of the parcel boundaries to improve accuracy an so on.

In any of the above mentioned situation the surveyor may use one of the surveying methods like: metric tape, theodolite, total station, GPS, etc. The choice of the measuring technique depends on the purpose of measuring, the required accuracy, and the costs involved. After field survey, the measurement will be processed and stored into a cadastral database — if one exists — or in other forms of data storage, like paper maps and documentations.

In this section we will create/simulate a use scenario for field surveying using a mobile device (PDA, Smartphone, etc). This scenario is based partly on the cadastral survey experience in five European countries, as described in section 2.3. To build the use scenario, we will follow the guidelines given by Hull et al. (2005).

The system shall allow a surveyor to use a mobile device for cadastral data collection in the field. Although a field survey is carried out for different reasons, here, only for simplicity reasons, we will restrict the scope of the system for measuring only new land parcels. Thus, the system shall allow the surveyor to measure a new land parcel, i.e., the boundaries will be measured for the first time and stored in a cadastral database. We are assuming that a cadastral database exists and the information can be stored and retrieved from it. The measurements of the parcel boundary points shall be done by means of GPS, which is integrated into the mobile device or can be con- nected with a mobile device. For each measured parcel, the surveyor shall be able to collect some descriptive information such as the municipality (administrative area), address, land use (agricul- ture, forest, pasture, construction), area, taxation value, and name of the owner or user. Besides, the system shall allow the surveyor to load the map of the neighboring properties (if they exist) from the cadastral database, and use the map during survey to aid the measurement.

In case there is a building on the land, the system shall allow the surveyor to measure the outlines of the building and record some descriptive information such as identification number, built area, number of floors, purpose, and construction permission.

The system shall be able to convert the measured points of the boundary into a parcel polygon

and store it in the cadastral database. Before entering the database, the newly created polygon shall

be checked for consistency with some existing rules. Such rules could be: the allowed topological

relationships between parcel polygons, the coordinates should be measured (or transformed) in

the reference system specified in the database, each cadastral parcel must have a unique identifier,

and on. Similarly, there may exist constraints that regulate the spatial relationship between land

parcels and the buildings they contain. However, the decision of which rules to implement into

the proposed system for mobile field data collection depends on the implementation of the exiting

cadastral database (some rules could already be implemented in the database).

We are also assuming that there exists a utility database (which resides in municipality or any other institution) which is accessible by cadastral surveyor in the field. The system shall allow the surveyor to access the utility database and check if there is any overlay of the utility lines with the boundary of the measured parcel. If there is overlay, the surveyor shall be able to record a restriction/servitude on the property.

We already mentioned that the surveyor should be able to record the address of the parcel being surveyed. Such information shall be retrieved from the municipality - being the responsible organization for assigning addresses - under the assumption that the addresses database exists in the municipality and is accessible from the field.

The mobile device shall be able to communicate with the sources of information to send and receive data. In absence of any communication network, the system shall allow the surveyor to store the surveyed information locally in the mobile device. It should be able to transfer the data from mobile device storage into database in a later moment when the communication is established.

To summarize, the surveyor shall be able to carry a field survey using a mobile device. The system shall allow the surveyor to access different sources of information during the field mea- surement. The cadastral database will be used to retrieve and store information while utility and addresses databases will be only used to read information. Thus, the mobile device should be provided with functionalities that allow the access and process of the information from those different sources.

The required capabilities of the system are presented hierarchically in Figure 2.1. At the top of the hierarchy is the main goal of the system, stating the capability of the system for field survey.

Every node in the hierarchy expresses a required capability which may be achieved using some other capabilities, in the next level of the hierarchy.

The Survey new parcel capability is achieved through several capabilities, which translated into steps of the use scenario, are performed sequentially starting from the top. This is shown in the Figure 2.1 by the word sequential under the proper node. In other nodes the sequence of operations is not important; this is the case with the node Collect descriptive data whose sub- nodes represent steps that can run in parallel. According to Hull et al. (2005) the time sequence is important because it simplifies the use scenario for the user and also helps to put the requirements into a context. However, this time sequence may change at the system implementation phase.

From Figure 2.1 can be seen that some capabilities like Create polygon, Survey boundary points, etc., are repeated several times throughout the use scenario. They do not represent different capa- bilities; instead they should be seen as the same capability needed by the user at different moments during the field measurement.

2.5 NON-FUNCTIONAL REQUIREMENTS

Beside the functional requirements for the mobile data collection system, there may be some constraints to it as well. A constraint is a non-functional requirement (Liu, 2002) that controls the way in which the required capabilities should be delivered (Hull et al., 2005; Gorton, 2006).

Some of the non-functional requirements are described in the following sections.

2.5.1 Business constraints

The proposed system should be generic and interoperable with SDIs as it will consume their

services.

Figure 2.1: Field survey scenario

2.5.2 Quality attributes

One of the issues for the proposed mobile data capture system is the security. Due to the sensitiv-

ity of the cadastral data, not every user equipped with a mobile device or a desktop computer is

allowed to access and update the information. Thus, the system must provide access only to users

authorized by the competent organization (e.g., the cadastral organization in charge of cadastral

data storage and maintenance). However, the intention here is not to provide security for the

cadastral database, as that is out of the scope of this research. Instead the system should provide

a simple mechanism for user identification. Reliability is another non-functional requirement for

the system. When lacking the communication network, the system should be able to store the

data collected in the field, and at a later stage when communication is re-established, it should be

able to synchronize with the cadastral database. Portability is another desired characteristic as it

will not tailor the system to any specific platform or device. Thus the system should be platform-

independent and also device-independent. In principle any type of mobile device (Smartphone, PDA, TabletPC, Notebook) running any operation system can be a potential candidate to do the job. However, mobile devices range from Smartphones to Notebooks (Casademont et al., 2004), with different operating systems and characteristics and it is practically impossible to cre- ate an application that can be used in such wide range of devices. In this sense the platform- and device-independence constraint is a characteristic that can only be fulfilled up to some level.

Nevertheless, a mobile device is eligible for the field survey scenario if it is equipped with Global Positioning System (GPS) receiver (or it is capable to connect to an external one), is able to run third parties applications and also capable to use wireless networks for communication.

2.5.3 Technical constraints

It should be obvious by now that a mobile device (Smartphone, PDA, TabletPC) will be used in field for cadastral data collection. The relatively small size of the mobile device makes it suit- able for the job as it is portable and lightweight. On the other hand, the mobile device has technological restrictions such as small display screen, small and slow memory, limited power autonomy, limited processing capabilities, special input devices, and low communication band- width (Brinkhoff, 2008; Rabin and McCathieNevile, 2008). All these technological restrictions will affect the design of the proposed mobile system for cadastral data collection.

2.5.4 Accuracy constraints

Within a cadastre organization the accuracy of the field survey may be a concern. Actually, based on the importance of the measurement accuracy of the cadastral boundary, cadastral systems can be grouped into fixed and general boundaries cadastral systems (UN/ECE, 1996). In the former group, the boundary is measured accurately and, if needed, can be restored in the field from the measurements. In the case of the general boundaries system, there is no accurate measurement of the boundary line. Instead, it is defined by natural or man-made features, such as hedges and fences.

For the fixed boundaries system, the accuracy of the measurements of the mobile phones’

GPS (several meters horizontal accuracy) may not satisfy the requirements. However, the mobile phone technology is developing in a fast pace. For instance, nowadays mobile phones are equipped with Assisted GPS (A-GPS) technology. A-GPS uses a remote server which provides information about satellite orbits, clock information, the initial position and time estimate, etc, resulting in fast time-to-first-fix (Zandbergen, 2009). In the coming years it is expected that more satellites will be available, which will improve the GPS accuracy of the mobile phones up to the level of centimeters (McLaren, 2010). Therefore, in this research, we will focus on the other requirements and constraints.

2.6 SUMMARY

In this chapter we have given an overview of the cadastre and land information systems in different

countries. The aim was to identify the process of field data acquisition and in that context a use

scenario was created. The use scenario describes the user requirements for a mobile data capture

system, in terms of what the system should provide rather than how. The user requirements are

the input of the analysis and design processes that follow in Chapter 3.

Chapter 3

Analyzing requirements for cadastre data collection

3.1 INTRODUCTION

In a system development process, the analysis and design are two logical steps that follow the user requirements collection. We start with reviewing some of the modeling and design approaches and methods which can be used for analyzing and designing the system (section 3.2). In the analysis phase, we transform the user requirements into a use case and create a first architecture of the system (section 3.3). We continue with the design step, by decomposing the system down into components and assigning responsibilities to them (section 3.4).

3.2 MODELING AND DESIGNING APPROACHES

Different modelling styles and patterns are available for analyzing and designing a system. Before reviewing some of the exist modelling approaches, we give some definitions of the main terminol- ogy used in those approaches.

• System: According to Hull et al. (2005), “a system is a:

· collection of components — machine, software and human —

· which cooperate in an organized way —

· to achieve some desired result — the requirements.”

Moreover a component of a system can be seen as a system itself, or further, a system can be a component of a larger system (Morales, 2004).

• Model: A model is an abstraction of a system that captures some of the characteristics of the system, while the irrelevant ones are left out (Hull et al., 2005; Morales, 2004).

• Architecture: The Institute of Electrical and Electronics Engineers, Inc. (IEEE Computer Society, 2000) defines the architecture as “the fundamental organization of a system embod- ied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”.

3.2.1 Development approaches

In the design and development of systems in general, and softwares in particular, different ap-

proaches are used. We have reviewed several approaches and describe them briefly in this section,

trying to bring out their characteristics.

Waterfall and Iterative approaches

The waterfall method is one of the earliest of the development models, first described by Winston Royce in 1970 (Kruchten, 2004). In this strategy, the development of the system is conducted through several phases, where one phase starts after the previous is completed and approved (Morales, 2004; Sommerville, 2007). This approach is based on the assumption that the user re- quirements will not change during the development process (Morales, 2004), which makes it not suitable in situations where requirements are changing during development process (Sommerville, 2007). Nevertheless, the advantage of waterfall model relies in the fact that it is predictable and the architecture of the system can be planned in detail which is important when developing large systems (Petersen et al., 2009). To improve the waterfall model, a more iterative approach has been developed. The development process is executed in iterations, where each iteration goes through all development phases (Morales, 2004). The advantage of introducing iterations is that the system is tested in every iteration and is improved (Morales, 2004).

Object model

In contrast with the structured design methods which use algorithms as their building blocks, the object-oriented design methods use classes and objects as building blocks (Booch et al., 2007). Ba- sically, the object-oriented development has two phases, the analysis and design. During analysis, the requirements are examined from the perspective of objects as found in the problem domain.

On the other hand, the design phase is led by the object-oriented decomposition process in which the system is decomposed into parts (objects). According to Booch et al. (2007), “the support for object-oriented decomposition is what makes object-oriented design quite different from struc- tured design”.

Decomposition is a strategy to handle complex systems, during which the domain of interest is divided into conceptual classes (Larman, 2002). Larman (2002) defines the conceptual class as a “real-world concept or thing”. Arlow and Neustadt (2002) use another term for the conceptual classes; they call them analysis classes which represent “real-world business concepts”.

The conceptual classes identified in the domain of interest, may have attributes. Larman (2002) defines an attribute as “a logical data value of an object”. Besides, the conceptual classes may be connected to each other through associations. Associations are meaningful connections between classes (Arlow and Neustadt, 2002), and define the visibility between objects. “Visibility is the ability of an object to ‘see’ or have a reference to another object” (Larman, 2002). To support the associations, classes have responsibilities. “Responsibilities are the essential duties that have to be performed [by an object]” (Hunt, 2000). The responsibilities of an object are of two types:

knowing — about their attributes, other objects, or things that need to be calculated; and doing — an object does something like performing an action itself, initiating an action in another object, or controlling the activities in another object (Larman, 2002).

Because the object-orientation analysis and design is built on exiting methodologies, it is con-

sidered an evolutionary development (Booch et al., 2007; Norman, 1996). The main benefit of

using the object-oriented model is that it can be used to build complex systems, that are diffi-

cult to build using other methods (Booch et al., 2007; Norman, 1996). Booch et al. (2007) give

some more benefits of using the object-oriented model. Some object-oriented approaches such as

the Booch Method, the Object Modeling Technique, the Objectory Method, the Fusion Method, etc, are

reviewed by Hunt (2003).

Design patterns

In object-oriented design, a design pattern is a solution to a problem, which may also give advices on how to be applied in a given context (Larman, 2002). The Controller is a design pattern which states that the responsibility to handle a system event is assigned to a class which, among others,

“represents a receiver or handler of all system events of a use case scenario” (Larman, 2002). The Creator is another one. It suggests assigning the responsibility for creating an instance of a class to an object that records the instance. These and other patterns such as, Expert, Low Coupling, and High Cohesion, are described in details by Larman (2002).

The Unified Process

The Unified Process “is a generic process framework [for software development] that can be specialized for a very large class of software systems, for different application areas, different types of organizations, different competence levels, and different project sizes” (Jacobson et al., 1999).

It is based on components and their interactions, i.e., a software is made up of components that interact through their interfaces (Jacobson et al., 1999). What makes the Unified Process unique are its three aspects:

• Use-case driven: A use-case shows how the user interacts with a system to perform a task.

Thus, a use-case captures the functionality required from the system. In the Unified Process, the use-cases are used throughout the development process; use cases are specified, designed, and at the end are used to create the test cases.

• Architecture-centric: The architecture captures the most important aspects of the system, leaving out those less important. It starts to grow from the need for the system and reflects the use cases. Then, it evolves at each step and is referred throughout the Unified Process.

• Iterative and Incremental: The Unified Process splits a software development into minipro- jects (iterations). Each iteration is built in such a way that it deals with those use cases that extend the usability of the system being developed, and it also deals with the most impor- tant risks in the development process. At every iteration the design is based on the state of the previous iteration and continues through the development phases to create an improved version of the system, hence the process is incremental.

A more extended review of the Unified Process is given by Hunt (2003).

3.2.2 The Unified Modeling Language

The Unified Modeling Language (UML) is developed at Object Management Group (OMG) and became a standard in 1997 (Booch et al., 2007). It is “OMG’s most-used specification, and the way the world models not only application structure, behavior, and architecture, but also business process and data structure” (OMG, 2010).

An introduction to UML is given in (OMG, 2005). According to OMG (2005), UML is built on Object-Oriented fundamentals and as such it is suitable for modeling applications that will be built using object-oriented languages and environments, but it can also be used to model non- object-oriented applications as well.

The UML has several diagrams which are combined into models that describe the system

being developed from different perspectives (Hunt, 2003; Hull et al., 2005). The UML 2.0 version

(released in July 2005), contains 13 diagrams, which are divided into three groups:

• Structure Diagrams: include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. This group of diagrams is used to model the static structure of the system;

• Behavior Diagrams: include the Use Case Diagram, Activity Diagram, and State Machine Diagram. These behavior diagrams, together with the interaction diagrams, are used to model the dynamic behavior of the system;

• Interaction Diagrams: include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram (all derived from the more general Behavior Diagram).

The UML is not a methodology or a process; indeed it is a notation that can be used to describe the models of a system under development and does not tell anything about how to design the system (Hunt, 2003). The widespread support for the UML derives from the fact that it does not depend on any analysis and design approach, which means that UML can be used to represent the result of any analysis and design approach (OMG, 2005).

A more complete review on UML, where diagrams are described in details, is given by Booch et al. (2007).

3.3 ANALYZING USER REQUIREMENTS

From the aforementioned development approaches, we use the Unified Process to guide an object- oriented analysis and design of the mobile data collection system. The reason for choosing this approach is related with the iterative and incremental nature of it. This characteristic of Unified Process allows to develop the functionality of the system incrementally through several iterations.

One of the benefits of applying such approach is that risks (technical, requirements, usability, etc) are found and addressed in early stages (Larman, 2002; Booch et al., 2007). The Unified Modeling Language will be used to draw the models derived during the Unified Process development.

3.3.1 System in context

During analysis phase a model of system’s behavior is created (Booch et al., 2007). This model is about what the system does without showing how it does it. To model the system behavior, we start by first defining the environment in which the system will operate. Figure 3.1 shows the system boundary and the interacting actors—the field surveyors who will use the system,— and also the SDI nodes which will provide services to the system. In other words, a field surveyor will use the system to survey a cadastral parcel; the system, on the other hand, will consume services of SDI nodes (cadastral, municipality, utility) to fulfill the user’s needs.

3.3.2 Defining use cases

To identify the use cases of the proposed system we follow the guidelines given by Larman (2002),

which introduces the idea of elementary business processes and goals as a framework for iden-

tifying the use cases. Larman (2002) defines the elementary business process (EBP) as: “A task

performed by one person in one place at one time, in response to a business event, which adds

measurable business value and leaves the data in a consistent state”. Further in his reasoning,

Larman (2002) refers to EBP-level use case as user goal-level use case, because a use case serves

the goals of the user. Thus, a use case for the proposed system is Survey Parcel. It represents a

task performed by one person — the surveyor — in one place at one time, in response to a busi-

ness event — the need to measure the parcel, — which adds measurable business value and leaves

Figure 3.1: Mobile Data Collection System, Context Diagram

data in a consistent state — updates the cadastral database whose consistency is guaranteed by its constraints. Thus, the Survey Parcel qualifies as a use case.

We write the use case for the mobile data capture system, using the template from Cockburn (1998). It comes in plain text and table forms, from which we use the latter as it offers a more structured description. Table 3.1, describes the Survey Parcel use case. Although the use case template contains many elements, in Table 3.1 we have used only those relevant to our use case.

The use case may contain many branches and unsuccessful paths (many things may go wrong during a field survey), but for the simplicity’s sake, we here represent only the successful path.

Table 3.1: Survey Parcel use case

USE CASE 1 Survey Parcel

Goal in Context To survey a property parcel in the field.

Preconditions Users are known and identifiable. Available and accessible wire- less networks.

Success End Condi- tion

Parcel is surveyed and stored in the cadastral database.

Primary Actor Surveyor.

Secondary Actors Cadastral, Municipality and Utility SDI nodes which offer ser- vices to the system.

DESCRIPTION Action

1. Surveyor starts a communication with the system.

2. Surveyor enters his/her authentication information.

3. Surveyor requests the cadastral map of the area of interest from the Cadastral SDI node.

4. Cadastral SDI node supplies the cadastral map.

5. Surveyor measures the boundary points of the parcel.

6. System stores measured boundary points.

7. System converts the coordinates of the boundary points into the reference system used by the cadastral organization.

8. System creates parcel polygon from boundary points.

9. System stores the parcel polygon.

Table 3.1: (continued)

10. Surveyor collects descriptive information on parcel such as identification number, municipality, land use, area, taxation value, and owner’s name.

11. System stores the descriptive information.

12. System requests the address of the parcel from the Munici- pality SDI node.

13. Municipality SDI node provides the parcel address to the system.

14. System stores the address of the property.

15. System requests utility data from the Utility SDI node.

16. Utility SDI node provides utility data to the system.

17. System overlays parcel boundary with utility data.

18. Surveyor measures the boundary points of the building.

19. System stores the measured boundary points.

20. System converts the coordinates of the boundary points into the reference system used by the cadastral organization.

21. System creates building polygon from boundary points.

22. System stores the building polygon.

23. Surveyor collects descriptive information on building such as identification number, built up area, number of floors, pur- pose, and construction permission.

24. System stores descriptive information on building.

25. System sends the surveyed data, of parcel and building, to the cadastral SDI node.

26. Surveyor ends the field surveying.

EXTENSIONS Branching Action

17a. If parcel boundary overlays with utility data, the system sends notification to the cadastral SDI node for putting restric- tion on the property.

17b. If parcel boundary does not overlay with utility data, sys- tem takes no action.

RELATED INFORMATION

Performance The surveyor should be able to survey a property within several minutes (depends on the size of the property parcel).

Frequency The system should be used any time there is need to survey a parcel.

Channels to prima- ry actors

Interactive graphical user interface.

Channels to secon- dary actors

Wireless internet communication channels.

The use case diagram in Figure 3.2, shows the interaction of the system with the actor (field surveyor), and with the SDI nodes. The arrows of the connection lines show which one uses the other. For instance, the actor will use the system to perform a field survey. On the other hand, the system will invoke the SDI nodes’ services to fulfill the actor’s requirements.

Another way to specify a use case, besides using textual description, is the UML activity

Figure 3.2: Survey Parcel Use Case Diagram

diagram. The later is used because it can reveal potential problems that are not visible in the textual specification representation (Booch et al., 2007). We created the activity diagram which shows the flow of activities in the system (Figure 3.3).

3.3.3 Defining system architecture

So far we have created a use case, Survey Parcel, and have used UML use case and activity diagrams to explain it. The activity diagram, in Figure 3.3, shows that most of the activities are run on the mobile device. Mainly, the activity diagram captures the functional requirements of the system, but also one non-functional requirement, namely, the one that controls the user access on the cadastral data. The SDI nodes column in Figure 3.3 represents the three SDI nodes we have already mentioned in the use case. They are outside of the mobile data collection system and are included in the activity diagram only to show a complete view of the activities.

While developing the system, besides the functional requirements, we have to consider the mobile device-related constraints. Mobile devices, because of their small size, suffer from lim- ited resources such as small screen, small battery, limited memory size and computing power, and limited keypad as compared to a desktop computer. Wireless networks are also slower and more expensive compared to wired networks. Moreover, they are not stable (the device may lose wireless connection).

Such limitations of the mobile device and wireless network impose some restrictions on the

architecture of the system. In this situation, we introduce another component in the system,

called SDI node for mobile client – SDImobile. We believe that this new element will allow us to

build a system that minimizes the usage of the mobile device resources. The SDImobile element

will serve as a “bridge” between the mobile device and the other SDI nodes. It will handle the

communication between them and run some of the activities in support of the use case. Further

analysis will reveal the SDImobile’s full role. Therefore, we build the logical architecture of the

system which includes the mobile device and the SDImobile component (Figure 3.4). Figure 3.4

includes also the three SDI nodes which, as already mentioned, are not part of our system. We

include them here just to clarify the role of the SDImobile in the interaction of the system with

those SDI nodes. The mobile device communicates with the SDImobile through its interface

(ISDImobile). Similarly, the SDImobile component interacts with the other SDI nodes through

their interfaces (ICadastre, IMunicipality, and IUtility).

Figure 3.3: Activity Diagram

We have rebuilt the activity diagram such that it includes the SDImobile component (Figure 3.5). Although it seems like a lot of activities are still running on the mobile device, that is not completely true. Most of them are requests asked by the user (using the mobile device) for activities that will run on the SDImobile. Thus, they will not consume as much resources from the mobile device as opposed to the prior situation (Figure 3.3).

3.3.4 Domain model

In this section we identify the conceptual classes and represent them in a domain model. To identify conceptual classes in the domain of interest we use the noun/verb analysis (Arlow and Neustadt, 2002). According to this method, the noun and noun phrases in a use case specification indicate classes or attributes of classes, while verbs and verb phrases indicate operations of classes (not identified in this phase). Another method for identifying conceptual classes is to use a list of conceptual class categories (Larman, 2002). In this method, as the name suggests, a list of conceptual class categories is used to identify conceptual classes. Some common categories are given by Larman (2002, pg. 134-135). In our analysis, we combine both methods for identifying the classes in our domain of interest. For instance, using the noun/verb analysis, in the use case action “5. Surveyor measures the boundary points of the parcel”, we can identify three nouns, Surveyor, boundary points, and parcel. Hence we have created three conceptual classes, Surveyor, BoundaryPoint, and Parcel. Similarly, we have identified the attributes (municipality, area, owner, etc.) of the class Parcel from the use case specification. By using the list of class categories we have identified classes like: MobileDevice, SDImobile — which belong to “physical or tangible objects”

category; Survey — which belongs to “processes” category; and so on.