The leading platforms in modern software development for applications with the user interface are web and mobile platforms. In the earlier days, it was common that the purpose of the client side of these applications only display data and process interactions, while the backend ran all business logic in the background. Recently a new trend can be identified that the client apps include complex business logic as well. Modern web frameworks and mobile technologies rely on the client device's computing capacities for the maximal performance, therefore provide built-in services to cache data and run steps of the business logic on the client device. This paradigm is illustrated by the success of PWA technology and by ofline applications. The user interface of modern applications is designed by UX designers, who focus rather on the ease of use and user experience then safety and soundness, which often leads to disrupting the well-defined business process by introducing new sub-steps and alternative ways. These tendencies altogether result that the client-side of modern applications also implement a lot of business logic that already implemented by the backend in a more strict, straightforward approach. In a more abstract approach, the client and the server work with the same type of documents by performing two diferent business processes that exist at the same time. The two layers of the application are often developed by diferent teams, where frontend and backend specialists work simultaneously. Altogether this results in new risks that should be mitigated by continuously evaluating the consistency of the two business processes during the whole development life-cycle. This evaluation should identify if the two processes
are consistent, special tools have to be introduced that ensure that after performing a particular iteration in the development roadmap, the consistency is still maintained. The goal of this paper is to introduce a formal model for this evaluation and introduce tools that can be derived from this model and can be used in software development and testing. MSC: 68N30
Client-server architecture is the most common and most important approach in modern software applications. The majority of user applications follow this model of architecture. The reason lies in the currently wide-spread web and mobile platforms opposite to those of desktop applications of the early 2000 years. Most of the business, communication, and social media applications are web applications where the back-end system naturally organizes data exchange of the apps on the central database.
Early so-called 1.0 web applications worked as thin clients as no code was
running on the client-side, and the client displayed the HTML mark-up and forming
command provided by the server. As a consequence, applications were hardly
responsive because all user interaction resulted in a reload of the whole website.
[
The situation has generated the demand for programs running on the
clientside, therefore Javascript support was added to web browsers. Javascript support
and and the AJAX [
As a further enhancement of AJAX technology, modern client-side frameworks
were developed which were capable to build Single Page Applications (SPA). In
SPAs after initially loading the client-side application, the browser uses standard
APIs (RESTful, GraphQL) to communicate with the server, and the client side
logic maintains the DOM elements. The first such frameworks were Backbone.js,
AngularJ, which were built around MVVM architecture[
For mobile applications at an early stage, software tools, and frameworks (iOS / Objective-c, Android / Java) were available, which enable them to run complex business logic. Currently, Swift programming language in the iOS environment and Kotlin in Android are the mainstream tools for application development. Both follow the MVVM architecture, and both have API support to connect to the back-end.
The mainstream approach in original client-server applications is the fact that data and business logic is implemented on the server side. As to run business logic on the client-side is a necessity for several reasons, modern web and mobile applications challenged this model.
One of the typical reasons is the goal to save computing capacities on the
backend load. If all business logic is implemented on the server side, the load on the
back-end increases together with the increasing number of clients. It is logical to
distribute some of the tasks to the client-side as the available computing capacity
and memory is constantly increasing. In the most advanced solutions, the server
benchmarks the clients and based on the results decides whether to perform a
computation (e.g., sort a data set) or to assign the task to the client. [
Another typical reason is that in modern applications development the user
experience is also in the focus on top of the basic task of implementing a certain
business workflow. [
Another use-case is when a complex process on the server-side is deconstructed
into elementary steps, which are easy to understand hence easier to use for the user.
The typical scenario is to divide a complex form into a series of simpler forms. The
goal of this approach to decrease the probability of error by the user and to increase
conversion. Churn in a process is lower in the data collection process when in each
step only one question is shown, while the total amount of the fields remains the
same. [
Ultimately, the goal is to construct a workflow model, from which the specification can be deducted for the backend and frontend software development, and also which helps to recognize if a backend and frontend specification is consistent.
Business logic modeling with workflow models has been an active field of research in the last few decades; therefore, several models are available. In this study, we propose a document-oriented workflow graph approach.
Workflows are usually represented by directed graphs, where nodes represent
activities to perform and directed edges define the control flow, usually an edge from
activity A to activity B indicating that A has to be completed before B and that
some of the output of A is the input of B. There are several models available to
define workflows, for example UML state machines [
Documents are defined as [key, val] tuples, where key is a text identifier field, val is either a value from the available atomic typesets, a document itself, or an enumeration of the aforementioned types. We denote he universe of documents by DOC. This is a traditional way to define documents, which is often provided by JavaScript Object Notation (JSON) or XML. { "name" : "John Doe", "expertise" : ["C++", "Java"], "certifications" : [ { "certification" : "Computer Science Msc.", "year" : 2010, "by" : "Eotvos Lorand University" }, { "certification" : "Computer Science Bsc.", "year" : 2008, "by" : "Eotvos Lorand University" }
A document schema is defined as [key,typename,multiplicity] tuples, where key
is a text identifier field, typename is either an atomic type’s identifier, e.g. ‘string’
or an already defined document schema identifier, multiplicity is a value from set
{1,*}, which denotes if the field is a value, or an enumeration of values from the
‘typename’ type. We denote the universe of document schemas as DS. A document
is based on a document schema, if it contains the fields and values according to the
keys, types and multiplicity specified in document schema.[
A document schema invariant is a first-order logical expression, where
document schema fields referred by selectors are used as variables in the expression. A
document satisfies a document schema invariant if the invariant logical expression
evaluates to TRUE under the interpretation where the selectors are mapped to the
actual document values [
The business process workflow is defined by WF: (V,E) directed, acyclic graph where V⊂Activities is the set of vertices, and E⊂VxV is the set of directed edges. In the following discussion vertex and node are used as synonyms. The activities are defined as [input, output, preCondition, postCondition, operation] tuples, where the fields are as follows:
Input ⊂ DT is the set of input document types, defined the following way. The input of v activity is Input={u.output | (u,v)∈E}. So the input is defined as the output documents of all u vertices from which an edge leads to v. Hence only those vertices have input documents that have incoming edges. The vertices that have zero input documents we regard as nodes that produce the output document requiring user input or from database queries. These vertices are called as entering nodes. We introduce the enterNode: WF → (V) function, which returns the subset of V, that contains all enter nodes and does not contain other vertices. There is exactly one vertex that does not have outgoing edges, which indicates the and of the workflow and is called finishNode. We introduce the finishNode(): WF→V function, which returns the w node that has zero outgoing edges.
Output ∈ DT is the document type that specifies the result document of the activity.
Each activity has preconditions and postconditions, that define constraints using first-order logic statements on input and output documents.
preCondition: Input → L postCondition: Output → L
In this study we do not aim to construct a new constraint language, instead we
regard these expressions as OCL contraints [
Operation: Input → Output function, which processes the input documents and result in one output document, which satisfies the following condition. For a given D set of documents if preCondition(D)=true, then postCondition(operation(D))=true.
Overall, the graphs’ edges indicate the order in which the activities have to be performed and the activities altogether with the edges define the input and output documents for each activity. The universe of such graphs is denoted by WFO. We regard such workflows that they provide a formal specification for implementation.
First we introduce a notation into the model, which indicates if a specific activity node has to be performed on the client-side,the server-side or both. For this purpose, we extend the previously introduced model.
The wf2=(V,E,S,C) is a client-server business process workflow graph where (V,E)∈WFO, where S⊂V, C⊂V, where all v∈S nodes are performed by the server and all u∈C activities are performed by the client. Note, that S and C are not disjoint by definition, which means that if w ∈S and w∈C mean that w can be performed by both layers. The universe of such graphs is denoted by WFCS .
The wf2=(V,E,S,C)∈WFCS workflow is called a server-side exclusive workflow, if S=V and C=∅, and called client-side exclusive workflow if C=V and S= ∅.
Now we introduce PrS: WFSC → WFO and PrC: WFSC → WFO functions, that functions return the server-side and client-side projection of a given WF∈WFO the following way:
WF=(V,E,S,C), WF’=(V’,E’),WF’=(V”,E)”
PrS(WF)=WF’, V’=S, E’⊂E |∀ (u,v)∈E’:u,v∈S and @(u,v)∈E where u,v∈S and (u,v)∈/E’.
PrC(WF)=WF”, V”=C, E” ⊂E |∀ (u,v)∈E”:u,v ∈C and @(u,v)∈E where u,v∈c and (u,v)∈/E”.
In the simplest case for a given wf=(V,E)∈WFO, if a given A⊂V set of activities have to be performed on client-side, simply create a wf1=(V1,E1,S,C)∈WFSC, where V1=V, E1=E, S=V and C=A, then calculate PrC(wf1), which results in the trivial workflow. This workflow is the specification for the client side.
If there are two given business process graphs, wf1=(V1,E1) and wf2=(V2,E2), where wf1 is regarded as the specification of the server-side and wf2 is regarded as the specification of the client-side, we can decide if the wf2 is compatible with wf1.
This is true, if wf1∈WFO can be extended to wf1’=(V1’,E1’,S1’,C1’)∈WFSC so that V1’=V1 V2, E1’=E1 E2, S1=V1 and PrC(wf1’)=wf2. In this case, the wf2 client-side workflow is compatible with wf1 server-side workflow.
So far we did not looked into the relation of workflows and activities. In the previously defined workflow model we defined the start and finish nodes of a given workflow. A wf workflow can be substituted by activity the following way: The input of the new activity is the union of output documents of entering nodes with the according postconditions. The output of the new activity is the output document of the finish node with the according postcondition. The operation is the logic defined by the workflow itself. We introduce the GW:WF →Activity function, where GW(wf)=a, where wf∈WFO and a=[in,out,preC,postC,operation], where in=inputNode(wf) out=outputNode(wf) preCV= {v.preCondition v∈inputNode(wf)} postC=outputNode(wf)preCondition,task
If GW(wf)=a for a given wf∈WFO , then the workflow is consistent with the activity and the workflow is the refinement of the a activity. We introduce RF:Activity→ (WFO ) function, where RF(a)={wf| wf ∈WFO and a=GW(wf)}.
If wf=(V,E,S,C):∈WFSC, and we select a subset A⊂C, and we substitute each a∈A with a wfs∈RF(a), resulting in wf’∈WFSC, then PrC(wf’) is consistent with PrS(wf). We can take also evaluate if a given wf1=(V1,E1) specification is available for the server-side and a wf2=(V2,E2) specification is available for the client-side if wf2 is consistent with wf1. The wf2 is consistent with wf1, if there is a wf3 graph that is compatible with wf1 and wf2 can be produced by a finite number of refinements from wf3.
Definitions and procedures described above will result in a formal tool that enables the analysis of the consistency of a particular business logic both on the server and client-side. The tools introduced will allow us to split a process specification into two specifications for both the server-side and the client-side. In other terms, a formal verification tool is given to decide whether the two separate specifications for the server and client-side are consistent. Based on the specification, automated unit tests can be generated from preconditions and postconditions, which help to verify the new program.
The above construction gives vent to further research. The next step would be the construction of an algorithm that would check the compliance and compatibility of separated processes as it is given in definitions 3.2.1 and 3.4.2 which can be later implemented. Further transformations of the business logic can be analyzed, which are applicable without damaging the consistency. Such a transformation type can be the introduction of processes and activities which can be executed in ad hoc order. Another question is whether the model is suitable for generalization for diferent architectures apart from client-server. Microservice architecture seems to be an obvious choice where processes would be distributed among microservices.