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

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

**1.** Many other process modelling tools are based on Petri Nets. The advantage of this method is that it is both graphical and has a solid mathematical basis. The best implementation of

**2.** Other approaches use diverse species of flowcharting. This method is the oldest graphical technique practised in computer science. It was originally used for visualising the sequences and control of computer program instructions. Nowadays, flowcharts are often used to express details of business logic. A very good application of flowcharts is workflow diagram applied in Proforma Workbench or FirstStep Business CASE Tools. Of course, it is also a sort of the activity diagram of UML [11] and a quickly expanding standard Business

**3.** The third approach used here is the use of automata finite-state machine (FSM). FSM has a solid theoretical background ([12] for example), as well as Petri Nets. A practical implementation of state machines is the state-chart diagram in UML, for example. Certainly, the

The overview of all approaches for simulation business processes described here is presented

CASE Tool, easy and clear method

Little link to possible subsequent software development techniques, slow analysis, low expressiveness of large

Too much computer based, difficult to understand by domain stakeholders.

Too much computer-based, difficult to understand by domain stakeholders.

Little link to possible subsequent software development techniques,

obsolete method.

models.

Petri Nets is the event-process chain (EPC) diagram from Aris methodology [10].

Process Model and Notation (BPMN, http://www.bpmn.org/).

sequence diagram of UML also includes some behaviour of FSM.

**Approach Theory behind Advantages Disadvantages**

Flowchart Industry standard, has many

for domain experts.

Notation (BPMN).

Flowchart Easy and clear method for domain

CASE tools with Unified Modelling Language (UML) or Business Process Modelling

Industry standard, has many CASE tools with Unified Modelling Language (UML).

experts, perfectly has many business CASE Tools.

EPC–Aris Petri Nets Very popular in Europe, has Aris

Finite State Machines

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

business modelling:

64 Modeling and Computer Simulation

in **Table 1**.

UML activity diagram or BPMN

UML Sequence Diagram and State Diagram

Workflow Diagrams

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 in Simone and Graham [9].

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 work, out of which BORM grew.*)

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 automata theory.

**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

**Figure 1.** A book and a borrower as two FSM.

In our method, the states of objects are the most important elements. Behaviours denote only the necessary linkage between them. Both business processes and software components should be consequently modelled by starting with their states—situations of participating objects in the requested system in some moment. Modelling can be simpler, more correct and less behavioural imperative than it is now. Moreover, our focus on situations matches the conventional description of life situations, as is known above all from descriptions of the

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

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

67

Likewise [3], we think that activities are key elements of business process modelling. Eeeles and Sims [13] describe a business process having a number of elements; activities, transitions, states and decisions. They assert that the UML activity diagrams can be a helpful modelling

In the organisation modelling, subsequent simulation is important that every participating object should be described as an automaton (FSM) with states and transitions dependent on the behaviour of other objects. Each state is defined by its semantic rule over object data associations and each transition is defined by its behaviour, necessary to transform the object from its initial to its terminal state. All organisational and business process models should be able to be simulated in this way. Hence, it should accent the mutual relationships (communica-

tions and associations) of states and transitions of objects in the modelled system.

implementing regulations and the various guidelines, decrees and laws.

instrument in recording business processes.

**Figure 3.** BORM and BPMN.

**Figure 2.** Two FSM mutually connected.

with an object of a book on loan in a relationship with cardinality of a 1 to many. That means, that every book on loan has to have its borrower and every satisfied borrower is satisfied if and only if he has at least one book borrowed. This is the possible business situation of our model. Similarly, we can identify the associations between borrower interested in borrowing a book and available books in the shelves. This association can be another possible business situation of our model.

Our given modelling approach unifies UML-manner of object modelling and business process modelling manner. Models like UML, BPMN and other can be easily derived from this BORM model. The proposed unified method unifies and simplifies object modelling. **Figure 3** presents the mapping of our model to the regular BPMN and **Figure 4** presents the same model represented by the state-chart of the regular UML.

The Role of Computer Simulation Tools in Improving the Quality of Life in Small Settlements… http://dx.doi.org/10.5772/intechopen.81244 67

**Figure 3.** BORM and BPMN.

with an object of a book on loan in a relationship with cardinality of a 1 to many. That means, that every book on loan has to have its borrower and every satisfied borrower is satisfied if and only if he has at least one book borrowed. This is the possible business situation of our model. Similarly, we can identify the associations between borrower interested in borrowing a book and available books in the shelves. This association can be another possible business

Our given modelling approach unifies UML-manner of object modelling and business process modelling manner. Models like UML, BPMN and other can be easily derived from this BORM model. The proposed unified method unifies and simplifies object modelling. **Figure 3** presents the mapping of our model to the regular BPMN and **Figure 4** presents the same

model represented by the state-chart of the regular UML.

situation of our model.

**Figure 2.** Two FSM mutually connected.

**Figure 1.** A book and a borrower as two FSM.

66 Modeling and Computer Simulation

In our method, the states of objects are the most important elements. Behaviours denote only the necessary linkage between them. Both business processes and software components should be consequently modelled by starting with their states—situations of participating objects in the requested system in some moment. Modelling can be simpler, more correct and less behavioural imperative than it is now. Moreover, our focus on situations matches the conventional description of life situations, as is known above all from descriptions of the implementing regulations and the various guidelines, decrees and laws.

Likewise [3], we think that activities are key elements of business process modelling. Eeeles and Sims [13] describe a business process having a number of elements; activities, transitions, states and decisions. They assert that the UML activity diagrams can be a helpful modelling instrument in recording business processes.

In the organisation modelling, subsequent simulation is important that every participating object should be described as an automaton (FSM) with states and transitions dependent on the behaviour of other objects. Each state is defined by its semantic rule over object data associations and each transition is defined by its behaviour, necessary to transform the object from its initial to its terminal state. All organisational and business process models should be able to be simulated in this way. Hence, it should accent the mutual relationships (communications and associations) of states and transitions of objects in the modelled system.

paradigm by incorporating non-traditional ways of thinking into the field of applied computer science. On OOP, the software system is modelled as an abstraction of the real world in the very similar way as it is in classical philosophy (e.g. models, meta-models, ontologies, objects…). The basic building concept is an object that incorporates both data structures and their functionality. Another modelling approaches handle data and behaviour independently, but OOP is based on their mutual dependency. OOP has been and still is explained in many books, but

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

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

69

In the field of theoretical informatics, the finite-state machines (FSM) theory is a study of abstract automatons and the problems they can save. An automaton is a mathematical model for an entity that responds to its external environments, receives data and produces another data. Automata can be constructed in a way that the output from one of them becomes input for another. Finite-state machine activity is determined not only by receiving data but also by an internal status of given machine. The output is created as the combination of an input and internal status. For example, the FSM theory is essential not only for the computer science and engineering, but also for a human language translation theory. It has been explained in

we consider that this early work [14] written by OOP pioneers is still the best.

**5.2. Finite-state machines**

**Figure 5.** BORM business diagram symbols.

**Figure 4.** BORM model decomposed into standard UML models.

BORM has been used for a number of large projects by Deloitte consulting company, Central Europe office in Prague, including

