**3. Organisation modelling**

preserving the conditions of the sustainable development (addressing living standard, cultural and historic value, agricultural and industrial production, transport infrastructure construction, tourism potential, etc.). Technophobia of local people significantly increases this problem because the low-level knowledge of local people is strongly contrasting with high knowledge of external people and (owners and investors for example) penetrating the rural area, who use good information and communication technologies (ICT) (especially geographical information

Business process models show the collaboration of more participants within the solved system. They also can be visually animated in case of need to teach participating people their roles. We need this approach for simulation, validation and verification of the real world problems from the area of agriculture, landscape management and country planning. A fundamental purpose of such a business model is to create and simulate a complex interconnected system, where local actors, citizens, regional government, various interested organisations and partners and other participants mutually communicate. In addition to that, business process models are also the foundation of subsequent system modelling activities of software engineering, organisational design and management consulting. The typical method of performing these activities is to start directly by drawing process maps without performing the initial interviews. However, we present the idea, which for better modelling, we need to use a specific textual technique, which helps us to recognise, define and refine our initial set of business process participants and their properties before performing any

In our experience, any modelling and simulation diagramming technique or instrument aimed for some real and practical projects should be intelligible to the stakeholders who are not typically well educated in ICT. Furthermore, these models must not inadequately simplify or distort requirement information. We recognised that the correct visualisation of the problem into the model and subsequent optional simulation is a challenging but essential task for standard diagramming techniques. We believe that the business community still lacks a powerful yet easy-learned tool for process modelling; capable of performing a comparable function to that operated by Flow-Charts, Entity-Relation Diagrams or Data-Flows Diagrams over the past decades. One of the strengths of these old techniques and tools was that they included only a restricted set of concepts (about 5) and were understandable by problem domain professionals after few minutes of learning. Regrettably, Unified Modelling Language (UML) and Business Process Model and Notation (BPMN) approach lost this advantage of clearness and simplicity.

Czech landscape development suffers from the low level of inhabitants' participation in small settlements of rural areas. We examined to model and visually simulate process-based knowledge about legislation about the urban planning and building development to obtain visual simulation an instrument for increasing the participation of local people in activities related

systems and project management) and process management knowledge.

graphical modelling activity.

62 Modeling and Computer Simulation

**2. Motivation**

to their real-life situations.

The organisation modelling is a necessary ingredient for the start of the whole system development life cycle. Darnton [3] and Taylor [4] say that the main obstacle (defined from the perspective of the software application development) with this step of the requirement analysis of socio-technical systems stands in the early steps of the whole system life cycle. The first step of any modern approach should contain two steps. The first one is the designation of the requirements in the form of business processes and their participants. The second one is the formation of a model, often called an essential object model or business object model, developed as a set of domain-specific subjects and participants known as essential elements. These two steps should be completed with the active participation of the domain experts, because they are able to guarantee that the accurate model will be made. Obviously, every modelling tool used at these early stages should be intelligible to the domain experts, because they are typically not skilled in ICT. Furthermore, these instruments must not damage or badly simplify requirement information.

The most used approach for business-process modelling in current object-oriented methodologies is use case modelling as the origin of the documentation process in UML. Jacobson founded the concept of use cases in the early 1990s [5]. The principal information source on UML is the website [6]. Ambler [7] says, use cases are usually the basis of most object-oriented development methods. Use case modelling consists of the identification of actors, which are external subjects communicating with the software section of the modelled system.

It is our experience that the accurate description of the system boundary is a troublesome duty, which usually needs deep knowledge of the proposed system, which must be included in the phase of system requirements specification. Some insufficiencies in this approach are stressed in Barjis [8]. There are miscellaneous opinions on the reasonability of use cases and similar instruments in the first phase of system modelling. Simons and Graham [9] very well explained examples where use case modelling could destroy the true logic and system behaviour. Unfortunately, standard UML-based tools are too oriented at the software engineering and programming logic, but there are yet another approaches for business modelling:

**4. Our Solution—BORM as the FSM and OOP combination**

in Simone and Graham [9].

*work, out of which BORM grew.*)

automata theory.

Our expertise in system modelling recommends that classical UML is not proper for the initial steps of analysis, where business processes must be identified. UML diagrams are too complicated for the users from the problems domain community as they oftentimes include extreme detail concerning possible software implementation. This involves classes, inheritance, public/private methods, attributes, link classes, etc. Nearly the same practice we have is written

The Role of Computer Simulation Tools in Improving the Quality of Life in Small Settlements…

http://dx.doi.org/10.5772/intechopen.81244

65

We conclude that the business community requires an easy but powerful tool for business process modelling and simulation; capable to perform an equivalent function to that performed by Entity-Relation Diagrams, Data-Flows Diagrams or Flow-Charts known in the past. One of the advantages of these timeworn tools was that they included only a little set of concepts (typically not more than seven), which caused them intelligible by business experts after a very short learning time. Regrettably, UML and BPMN method missed this power.

That is why we developed our own Business-Object Relation Modelling (BORM) process diagram and our own way to start business system analysis. The initial work on Business-Object Relation Modelling (BORM) was carried out in 1993 under the support of the Czech Academic Link Programme (CZALP) of the British Council, as part of the *Visual Application Programming Paradigms for Integrated ENvironmentS* (VAPPIENS) research project; further development and recent practical projects in the last decade has been supported by the Craft.CASE Ltd.—the British software consulting company supporting innovative technologies. (*VAPPIENS was financed by the British Governments CZALP, managed by the British Council. The authors acknowledge the support they received from this source, which enabled them to meet and carry out the initial* 

Our approach is founded on the reclaim of old thoughts from the early 1990s concerning the modelling of object features and behaviour by automata (FSM). The first book articulating the potential blend of the Object-Oriented Approach and Finite-State Automata was the Shaler's and Mellor's [12]. Taylor [4] wrote one of the best books speaking about the applicability of OOP to the business modelling. These early works together with our practical experience is the reason why we believe that the business requirement modelling and simulation and software modelling could be unified on the background of object-oriented approach and

**Figure 1** shows an example of a model of a book in a library characterised in a form of an automaton having three phases: a book on a shelf, a book on loan and a returned book to be put back on a shelf. These phases are easily recognisable through an interview with domain experts. When these phases are recognised, it is possible to identify behaviours required for transferring books between the states. Of course, other entities in the system can be also modelled as another automata, which mutually communicate to each other. Let us have a borrower as an example. Even they have their own phases, which can be related to the timerelated situations of the book; and analogically, the borrower's behaviour can be related to the book's behaviour, see **Figure 2**. This figure shows that a satisfied borrower is associated


The overview of all approaches for simulation business processes described here is presented in **Table 1**.


**Table 1.** Most used simulation approaches.
