Modeling Real Property Transactions: A Case Study Approach

1. COST G9 - Work group 2 meeting Székesfehérvár, Hu 02. 09. - 03. 09. 2004 Modeling real property transactions Radoš Šumrada Faculty of Civil and Geodetic Engineering Jamova 2, SI 1000 Ljubljana, Slovenia

2. Modeling real property transactions by work flows • (Swe and SIo cases) • Contents • Introduction and background • Presentation of the selected real property transacton cases • Methodology, tools and the overview of diagrams • Use case analysis • Analysis of work flows (activities) • Analysis of interactions (data flows and time span) • Comparison of results for the developed Se and Si models • Conclusions

3. Introduction The primarydecisionis to selectthe appropriate method for conceptual modeling in the spatial data problem domain. Appliedmodeling methodologyis based on the UML formalism (Unified Modeling Language) for visualization on the appropriate diagrams. According to the adopted methodology use cases for threeSwedish (Swe) and Slovene (Slo) real propertytransactions have been developed. The outcomes are presented on the use case, activity and interaction diagrams that are based on the detailed description of each use case.

4. Modeling real property transactions - the scope Regardig the scope and the level of modeling we elaborated the external or the user oriented approach and modeling of work flows. Different approaches internal procedures internal data structures internal data flows internal quality models efficency and effecitveness production line etc. Participants users / actors objects / classes other systems subsystems etc. Systems povide services liketasks, procedures, data etc. Users‘ approach external (users') views tasks and services real property transactions external business modeling Systems cadastral authority land registry population register tax authority etc.

5. Modeling real property transactions - examples • We choose to describe and model three selected real property transactions by applying the use case approach. • The elaborated use cases are as follows: • sale (conveyance) of a whole property unit or a parcel • with a detached house, • or as agricalcular land, • subdivision of a property unit or a parcel, • subdivision and sale of part of a property unit or aparcel. • The treatment of legal rights (pre-emptions, liens and easements) was also included.

6. Methodology and UML ontology(1) Use case represents the sequence of actions carried out by the system in order to provide selected service to its users. Actorsare users or other systems that interact with the modeled system. Use case analysisdescribes one or more paths through the activities that accomplish the case and as well all the possible scenarios. The main steps in use case analysis are the following: Identify and describe use cases, actors and the important interactions among the actors and use cases. Develop use cases from the general to the detailed descriptions.

7. An example of a detailed use case description for the SIo sale case

8. Use case diagram for sale of a agriculcural parcel (SIo)

9. roles phases Methodology and UML ontology(2) Objects worktogether to produce the functionality that actors require of the system. Each individual object provides only a portion ofthe functionality needed to accomplish certain service or use case. Activity diagrams are used to describe workflows such as flows in use cases, process or business flows. Collaboration is a set of objects, actors or participants that work together to achieve some services with meaningful outcome in the context of the system. Interaction is a sequence of messages sent between objects in the context of a collaboration in order to achieve the required functionality.

10. Roles and phases Activity diagrams are useful foranalyzing use cases, responsibilities andfor work process flow. We have developed adequate activity diagrams for all three mentioned use cases. Example shows activity diagram with roles and phases for the Slo subdivision case of a parcel.

14. Related problems • By modeling property transactions we try to overcome some conceptual problems: • How to compare different views on real property transactions (legal, professional, technical, economic etc.)? • How to reduce the multitude of possible relations among the actors and use cases? • How to precisely define the realization of certain activities (sequence or parallel)? • How to implement partly unclear or obscured scenarios (rule of thumb, lack of practical experiences, inadequate legal definitions etc.)? • How to compare the equivalent models from different countries with varying legal frameworks,public and privat restrictions, social settings and tradition?

15. Conclusions - technical view At the end we stress again that also for modeling of real propertytransactions it is crucial to follow the chosen methodology as the guiding process. Further on, the benefits of the standardized modeling language (UML) and its graphical notation are obvious, although the elaboration of certain detailed UML diagrams can be a demanding and consuming task. The availability of suitable, powerful and adaptable modeling tool (OOAD software) is also very important.

16. Questions and opinions? Friday, January 3, 2020 - 20:08:59

17. Main steps in problem domain analysis (1) Problem domain refers to the treated objects and concepts, which are related to the problem that weanalyze and designadequate solution. Domain analysisis the tasks of discovering objects, their classification, and further definition of their properties and relations. In general, the development and modeling process in particuar should be carried out incrementally and iteratively. The main steps in problem domain analysis are the following: Gatheravailable data and expertise about the legacyof the renewing system, similar existing systems,or user requirementsforthe new one. Identifyproblem domain objectsand drawhigh-levelclass diagramsthat introduce the basic datastructure.

18. Main steps in problem domain analysis (2) Perform classification (classes), generalization andaggregationin orderto derive the first cut structure of classes. Specify their basic properties (attributes) and main relationships (associations and other dependencies) among classes. Describe their basic functionality (activities) and importantmessages(communication) among classes. Identify packages (subsystems) and the general structure of the system as a whole.

19. Use case analysis and modeling (1) A use case is a sequence of actions that an actor performs within a system to achieve a particular goal that results as system service. By use case analysis we describe one or more paths through the activities that accomplish the case and as well all the possible scenarios. The main steps in use case analysisare the following: Identify and describe use cases, actors and the important interactions among the actors and use cases. Develop use cases from the general to the detailed descriptions.

20. Use case analysis and modeling (2) Define priorities of use cases. Elaborate each use case in all the required detail (main course and all the alternative scenarios). Present use case model on a set of use case diagrams. Organize use cases into the suitable groups. Present the organization of use cases and theirhierarchy on package diagrams.