This paper introduces a graphical modeling notation based on coloured petri nets for the performance and cost evaluation of mobile applications. When developing such an application some restrictions due to the low bandwith of mobile networks need to be considered. The notation can be used to model the workflow of an mobile application with just a small effort. The resulting model can be (automatically) transformed into a coloured petri net for simulating the communication behaviour depending on typical user interactions. The simulation results are an important basis for improving the applications performance and the occuring costs for using mobile networks.
Since the availability of mobile broadband networks and the reduced costs for
mobile devices the use of mobile applications has become an interesting
opportunity in several fields. Companies with large divisions of mobile employees (e.g.
service technicians, sales representatives, healthcare services) can use mobile
applications to gain access to corporate applications and databases at the point of
service (POS). Therewith better coordination of mobile employees, rapid task
assignment, the avoidance of error-prone format conversion, instant access to
customer data and many more becomes feasible [
For a succesful use of a mobile application the circumvention of these shortcomings is crucial. They are caused by the fact that a large amount of data needs to be transmitted via a small bandwidth network. Thus, an application designated for mobile use should be evaluated under consideration of the data volume transmitted for typical workflows at the POS, e.g. through simulation. On the basis of these results an application tuning for data intensive communication sequences can be performed. Obviously, the reduction of the transmitted data volume directly leads to an improvement of the given shortcomings. Therefore, we propose the following method: First, a model of the mobile applications’ clientside is needed describing the mobile workers’ workflow (or business process) in its single steps at the level of network communication respectively application dialogs. Second, an analysis of the model is needed regarding response times and costs. Third, the application need to be readjusted in order to meet defined performance and cost target values. In the following such a method is presented in detail.
The paper is organized as follows: Section 2 gives an overview about related work. Section 3 shows detailed requirements for the modeling and the analysis of mobile applications under consideration of the above defined situation. Section 4 introduces a petri-net-based graphical modeling notation for the defined purpose. The theoretical work is applied in a case study presented in section 5. Section 6 gives a short conlusion and shows our planings for further research. 2
The changes for the discipline of software engineering when developing systems
for mobile environments are discussed in [
A lot of work is done regarding system architectures and other technical
aspects of mobile system. An example for this work is [
Requirements for Modeling and Analysing the Communication Behaviour of Mobile Applications 3.1
Defining Evaluation Objectives
When analyzing the communication behaviour of a mobile application its
architecture is of particular relevance. According to [
In order to decide whether a certain application is capable for mobile use, concrete requirements must be defined, most suitable deduced from the mobile workers needs. Therefore the workflow (term used in the following as equivalent for business process) need to be modeled and analysed regarding the use of the mobile application. Thus, the later results can be availed to evaluate the application regarding workflows which e.g. are business critical, have many recurrences, or are important for customer satisfaction. The model should contain at least all steps in the workflow where the mobile application is used. Since the application uses a mobile network, its communication behaviour is of particular interest for the later analysis. Therefore each step in the workflow model should contain detailed information about the communication behaviour of the application which is mainly the data volume transmitted. For a better understanding of these contiguous aspects a short formal description is given in the following.
Be P a set of network providers and N a set of network types. Each combination (p, n) ∈ P × N is called wireless network. The volume-based fee f (p, n) for a certain unit for the usage of a network depends on the wireless network (p, n) ∈ P × N . The maximum upstream bandwidth bup(p, n) and the maximum downstream bandwidth bdown(p, n) depend also on the mobile network (p, n) ∈ P × N . A workflow consists of a set of activities A. One activitiy a ∈ A is characterized by the average sent data volume dvsen(a) an the average received data volume dvrec(a).
Based on these correlations, certain evaluation objectives can be deduced. For each activitiy a ∈ A the average request time tsa(p, n) as well as the average response time tra(p, n) tsa(p, n) = dvsen(a) bup(p, n) tra(p, n) =
dvrec(a) bdown(p, n) can be calculated. The overall transmission time of the activitys’ data volume is given through:
ta(p, n) = tsa(p, n) + tra(p, n) For an activity a ∈ A the volume-based fee for the sent data volume can be calculated with csa(p, n) and for the received data volume with cra(p, n): csa(p, n) = dvsen(a) · f (p, n) cra(p, n) = dvrec(a) · f (p, n) For each workflow activity a ∈ A the average number of recurrences ra can be calculated, e.g. through simulation. Thus, the average costs cw for one workflow recurrence is given by: (1) (2) (3) (4) (5) The volume-based fee for the overall transmitted data volume for an activity a ∈ A is given through:
ca(p, n) = csa(p, n) + cra(p, n) cw(p, n) =
ra · ca(p, n) for each a ∈ A Therewith seven basic criteria for the evaluation of a mobile application are defined. Of course this model could be extended with more aspects, e.g. allowing the change of the used network between activities, distinguishing costs on the activity level, allowing for volume-dependent fees, and modeling asynchronous communication. As stated above, we focus in this paper on web-based applications and therefore consciously introduced just basic evaluation criteria needed for the understanding of the further explanations. In the following, it is shown how to model the communication behaviour of the application in order to obtain meaningful values for the above defined evaluation criteria.
(requests/ryesstepmonascetisoenquence) (with onesyssutecmceestdainteg action) (wsuitchcsmeyesutdletiinmpglesatpacottiesosnibs)le
system state
(workflow termination)
control flow
For the modelling of workflows plenty of notations are available, but just a few
allow the simulation of the created model in order to obtain data regarding the
workflow and the applications’ communication behaviour. Considering this, we
decided to use coloured petri nets (CPN), which have a complete formal basis,
allow a very flexible modelling, and tools for the modelling and the simulation
are available [
B (dvReq, 1) AlternativeChoice (dvReq, 2) The corresponding graphical element contains a cloud representing the network to communicate with (see Fig. 1, utmost left hand side). The starting point of this system action is a system state from which the mobile worker initiates a network request, e.g. through clicking a hyperlink or submitting formular data. In case of clicking a hyperlink, the following response is usually clearly defined and leads to one possible system state (e.g. new webpage). However, in dynamic applications the result may vary over a certain range of defined alternatives depending on the user input. The system action simulates the incidence of one alternative with given probabilities. Furthermore, for both the request and the response it calculates the transmitted data volume from a given range.
This action is defined by a place-bounded CPN as shown in Fig. 2. The used data types and variables in this CPN are defined as follows: colset DataVolume = int; colset DataVolumeReq = int; colset DataVolumeRes = int; colset AlternativeID = int; colset AlternativeChoice = product DataVolumeReq * AlternativeID; colset WorkflowState = product DataVolumeReq * DataVolumeRes; var altID : AlternativeID; var a, b, dvReq, dvRes : DataVolume; A token in this CPN represents the actual position in the workflow and carries information regarding the transmitted data volume of the current communication sequence. If a token from type WorkflowState is put into place step A the transition network: send and receive fires. In doing so, the function randArcID randomizes from the given alternatives. For each alternative the probability is assigned, the overall sum must be equal to 100. The example in Fig. 2 consists of one alternative with probability 0.8 and a second alternative with probability 0.2. Furthermore, the function randDv randomizes the sent data volume dvsen(a) from a given range. Finally, the transition creates a token as output for place step B carrying the result of the function randArcID as altID and the result of function randDv as dvReq. The place step B has one or more succeeding transitions depending on the defined alternatives. As each alternative has an ID, the stAep (a,b) local: user choice (0, altID) step
B WorkflowState output (altID); action (randArcID([80, 20])); step D WorkflowState WorkflowState token from place B can just be processed by the transition that matches the tokens’ altID. The corresponding condition is specified at the outgoing arc of place B. The transition alternative x randomizes the received data volume dvrec(a) from a given range and stores it with the token as dvRes. The token now carries information about the sent data volume dvReq and the received data volume dvRes and is put into the following place (resulting system state). In Fig. 2 two alternatives are shown, but any number of alternatives is feasible. As we aim on hiding the complexity of CPN, the user can apply this net through the use of the appropriate symbol and need to specify just the variable attributes, which are the actions’ name, a range for the requested data volume, the number of alternatives, a probability for each alternative, and a range for the received data volume for each alternative.
System State (with multiple possible succeeding actions) In most of the cases, a system state will have multiple possible succeeding actions, e.g. a couple of hyperlinks. In this case each succeeding action will be choosen by the mobile worker with a certain probability. Hence, this system state is defined by a CPN as shown in Fig. 3. This system state is illustrated by a document symbol showing some arrows (see Fig. 1, third from left hand side). The used data types and variables in this CPN are the same as the ones above. The functionality of this CPN is slightly similar as the one explained before. The starting point is a system state, represented by a place (in Fig. 3 step A). If a token from type WorkflowState is put into this place the transition local: user choice fires. It randomizes from the given alternatives and puts the resulting altID on the token, placing it into place B. From there, only the corresponding transition having the right alternative ID at its incoming arc is able to fire and puts a token in the following place describing the choosen alternative. From there, the corresponding system action could start immediately. In Fig. 3 two alternatives are shown, but any number of alternatives is feasible. As we aim on hiding the complexity of CPN, the user can apply this net through the use of the appropriate symbol and need to specify just the variable attributes, which are the states’ name, the number of alternatives, and a probability for each alternative.
a.0 invoke URL mail.yahoo.com
s.1 display page login a.1 send login data
s.2 display page mail overview a.2 open inbox
s.4 display page inbox
s.8 display page confirmation
a.3 meospseange opae.n5 reply form a.4 delete message s.5 display page message
s.6 display page reply form a.8 send logout
s.9 display page logout s.3 display page failed login 6a.7 s.7 a.7 open display page send compose mail composing mail message A system state having one possible succeeding system action (e.g. one single hyperlink) does not need to be defined by a CPN. In fact, it matches with one of the source places respectively the drain places from a system action. Such a state is illustrated by a document symbol showing a single arrow (see Fig. 1, second from left hand side).
Each workflow has a defined end which is in our case specified through a system state. This state is illustrated by a document symbol showing a cross (see Fig. 1, second from right hand side). This state does not need to be defined by a CPN as it matches with one of the drain places from the preceding system action. 5
In the following we show, how the above introduced modeling method was applied for the yahoo mail portal. Many people are interested in accessing their mails also when they are away, e.g. using a notebook and GPRS or UMTS adapters. Thus, we would like to answer the question whether such mobile networks have sufficient response times for the given application and what costs occur when using them. First, we determined typical workflows that are of particular interest for us. That is checking the inbox for new messages, open a message, delete a message, reply to a message, and compose a message. Then we created a model of the mail portal using the above introduced notation. The result is shown in Fig. 4. The workflow starts with the invocation of the URL (network request/response cycle a.0). The server response contains the data for displaying the login page in which the user enters the login data (system state s.1). By clicking the submit button, the login data is sent to the server (a.1). Two server responses are possible: First, the login failed and the client shows a suitable page (s.3). Second, the login is successful and a mail overview page is displayed (s.2). From this point, several user actions are possible. If the user chooses to compose a new mail (a.6), the appropriate page is displayed (s.7). By clicking the send button, the message is sent (a.7) and a confirmation page is displayed (s.8). From there, the user can choose between returning to the inbox folder or to log out. In the latter case (a.8), a confirmation page is displayed (s.9). From the inbox folder (s.4) a message can be opened (a.3) and gets displayed (s.5). This message can be deleted (a.4), the user then returns to the inbox folder (a.2). The user can also reply to this message (a.5) using a reply form (s.6). The further steps are the same as described in composing message.
After creating this model, we need to specifiy arc probabilities wherever
different alternatives occur and we need to define minimum and maximum values
for the expected data volume which is sent and received. We collected the latter
data with a HTTP protocol sniffer tool. The resulting data is showed in Table
1 (values for system actions) and in Table 2 (values for system states). The
created model can now be transformed into the corresponding petri net according
to the above defined subnets. The resulting net is shown in Fig. 5. This petri
net can now be used for a simulation of a large number of workflow recurrences.
We did such a simulation with CPN-Tools [
When developing applications for their use with mobile networks, bandwith limitations and occuring costs need to be considered in order to assure the usability of the application at the POS. For already existing applications originally designed for usign in the LAN environment one need to cope with the same challenges when trying to make these applications available at the POS. Therefore, we presented a lightweight graphical modeling notation that can be used for modeling workflows within mobile applications. This notation is based on coloured petri nets and allows the simulation of the created model regarding the frequency of communication sequences as well as their costs and performance. The results of the simulation can be used for aligning the application to business and usability requirements through tuning the application at the right points.
Further research is planned in several fields regarding the shown method. First, we plan to extend the underlying evaluation model, e.g. through considering different bandwiths for up- an downstreams, allowing asynchronous communication etc. Second, we want to extend also our modeling notation in order to be able to describe more mobile application types, e.g. asynchronous communication with rich clients and offline clients with occasionally synchronization. Third, we work on a tool support for our modeling notation that will allow the automatically transformation of the created model into a CPN.