This document describes a model-driven method for the automated performance prediction of business processes. The method uses PyBPMN to specify functional and non-functional requirements, UML models to specify the design, EQN models to specify performance, and jEQN code to implement/execute the performance model. An example application is presented to validate the approach, showing how a business process for checking out orders is modeled and its performance predicted. The conclusions discuss how the method automates existing simulation approaches using model-driven standards and closes the gap between business process and performance modeling languages.

1. Mod4Sim 2012
2nd Workshop on Model-driven Approaches for Simulation Engineering
March 27-28, 2012
Orlando, FL, USA
Automated Performance Analysis
of Business Processes
Paolo Bocciarelli, Andrea D'Ambrogio
Dept. of Enterprise Engineering
University of Roma “Tor Vergata”
Roma (Italy)

2. Agenda
• Motivations and Objectives
• Background concepts:
 MDA principles and standards
 BP, Service-oriented Architectures (SOAs) and PyBPMN
 jEQN language
• Model-driven QoS analysis of BPs
• Detailed view inside the performance prediction step
 UML to EQN model-to-model transformation
 EQN to jEQN model-to-text transformation
• Example application and validation issues
TMS'12

3. Motivations and Objectives
• Limitations
 The use of simulation-based approaches for the BP analysis is
limited in practice. This is mainly due to the required effort and
skills
• Addressed needs
 Close the semantic gap between modeling languages for
specifying BPs (e.g., UML or BPMN) and modeling languages for
analyzing the performance of BPs (e.g., Petri Nets, Extended
Queueing Networks, etc.)
 Automate the existing approaches to BP simulations that are
mostly manual or show a limited degree of automation
• Proposed contribution
 A model-driven method that exploits PyBPMN and jEQN for
integrating performance prediction activities into the BP
development cycle
TMS'12 Andrea D’Ambrogio 3

4. OMG’s MDA principles and standards
• MDA Motivation: transfer the focus of work from coding
(“everything is an object”) to modeling (“everything is a
model”)
• MDA provides a set of guidelines for structuring specifications
expressed as models and transformations between such
models
• A transformation maps the elements of a source model that
conforms to a specific metamodel to elements of another
model, the target model, that conforms to the same or to a
different metamodel
• MDA provides the following standards:
 Meta Object Facility (MOF): for specifying technology neutral
metamodels (i.e., models used to describe other models)
 XML Metadata Interchange (XMI): provides a set of rules for
serializing MOF metamodels
 Query/View/Transformation (QVT): language for specifying
model transformations
TMS'12

5. Business process and SOA
• The term Business Process (BP) refers to the set of activities
that companies and organizations carry out to provide services
or produce goods
• A BP can be seen as a an orchestration of tasks, each one
related to the automated or human resources in charge of its
execution
• The automated execution of tasks
within a BP can be based on SOA
standards:
 SOA standards define a framework
that allows the composition of
atomic services to define and
execute higher level business
processes
 Web services represent a set of
technologies needed to define and
invoke remote software services
TMS'12 Andrea D’Ambrogio 5

6. Modeling QoS properties of a BP: PyBPMN
• This work exploits Performability-enabled Business Process
Modeling Notation (PyBPMN), a language to specify QoS
properties of BPs
• PyBPMN has been designed as an extension of the Business
Process Modeling Notation (BPMN), the standard language
for business process modeling promoted by OMG
• According to MDA the extension process:
 leverages on MOF (Meta Object Facility) and XMI (XML Metadata
Interchange)
 is based on a metamodel extension
• The extension specifically addresses:
 Performance modeling: UML Profile for Modeling and Analysis of
Real-Time Embedded systems (MARTE)
 Reliability modeling: research contributions that add the
description of reliability properties to MARTE [Petriu, Bernardi
and Merseguer, 2008]
TMS'12 Andrea D’Ambrogio 6

7. Model-driven QoS analysis of BPs: overview
• The proposed model-driven method exploits PyBPMN to carry
out the automated QoS analysis of a business process and is
integrated into a complete model-driven service composition
process
TMS'12 Andrea D’Ambrogio 7

8. Model-driven QoS analysis of BPs: performance prediction
• The performance prediction activity includes the following
steps
 the generation of the
EQN model describing
the orchestration of
concrete services
 the transformation of EQN
model into the jEQN
code
 the jEQN execution to
derive the performance
indices of interest
TMS'12 Andrea D’Ambrogio 8

9. Metamodel for Extended Queueing Network models
TMS'12 Andrea D’Ambrogio 9

10. UML to EQN model-to-model transformation
• The UML-to-EQN model transformation has been specified in
the QVT language
• The UML model used as input is obtained from the PyBPMN
specification
• The mapping of PyBPMN flow elements to UML AD elements,
and AD elements to EQN elements are summarized as follows
PyBPMN Element UML Element EQN Element
Closed Workload MARTE annotation Users/thinkTime parameters
(associated to Orchestrator) (associated to swimlane) (for Closed EQN)
Open Workload MARTE annotation Distribution of interarrival time
(associated to Orchestrator) (associated to swimlane) (for Open EQN)
Start/End Event Start/Final Node Terminal node (for closed EQN)
Task Source/Sink node
Opaque Action Node
(associated to Orchestrator (for open EQN)
Inclusive Diverging Gateway Fork Node Fork Node
Inclusive Converging Gateway Join Node Join Node
Exclusive Diverging/Converging
Decision Node Router Node
Gateway
Message Flow/ Sequence Flow Clontrol Flow routing within the EQN
TMS'12 Andrea D’Ambrogio 10

11. UML to EQN model-to-model transformation
• The mapping of each pair SendTask/ReceiveTask in the
PyBPMN model to UML AD and EQN is non-trivial
• To this respect, the proposed EQN model includes two classes
of jobs: toServe, to represent jobs which have to be served
by a participant, and Served, to model a job just served by a
participant
TMS'12 Andrea D’Ambrogio 11

12. ged to " Ser ved" ,
P
UML to EQN model-to-model transformation
ce Center, to model
A request to the next service center is structured as follows:
ce provider sends to EQN Model
1. job passes through the WAN release
Service Center, to model the set C1
request message that the
r at or Ser vi ce to the
orchestrator sends Token
Pool
he router R forwards
service provider
from Orchestrator
o 2. job passes through the
the Set C0 node ServiceCenter
R
[C0]
Participant Service Center, to
center. WAN
[C1] allocate Particpant
ServiceCenter
model the service execution to Orchestrator
ServiceCenter
performed by the participant set C0
N model has been
3. jobClass is updated as Served
thm 1 based on the
4. job passes through the Figur e 4. Mapping of SendTask/ReceiveTask p
WAN
on Service Center, to model the
describes some
N- t response message
o- j EQN model- jobclass is updated to toServe (C1)
jobclass is updated (C0)
toServe to Served (C0)
5. job returns to the Orchestrator
Service Center mapped to jEQN classes, except for Terminal and
that, due to design choices of jEQN, are to
ext tr ansfor ma-
TMS'12 Andrea D’Ambrogio
differently. 12

13. jEQN Overview
• jEQN is a Java-based Domain Specific Language (DSL) for
the Extended Queueing Network (EQN) domain
• jEQN founds on software engineering best practices, so that
it overcomes the limitations of currently available EQN
languages (i.e., lack of abstraction, semantic gap between EQN
conceptual model and the simulation language conceptual model, low
degree of customizability)
• jEQN is built on top of a software architecture that allows to
decouple the simulation logic of each component from the
coordination and communication logic of the simulation
container
• As a consequence, jEQN supports local or distributed
simulation by the transparent use of DS standards
• jEQN source code is available under Open Source GPL v3.0
license
http://sites.google.com/site/simulationarchitecture/jeqn
TMS'12

14. jEQN Architecture
Layer 4
jEQN Simulation
Language Layer
Layer 3
Implementation of the jEQN
Simulation Language
Layer 2
Execution Container
LocalEngine DistributedEngine
Layer 1 Distributed DES Abstraction
Layer 0 Any other Distributed
(Distributed Simulation HLA DIS Simulation Infrastructure
Infrastructure)
TMS'12 Andrea D’Ambrogio 14

15. EQN to jEQN model-to-text transformation
• The jEQN code that implements the EQN model is obtained by
use of a model-to-text transformation, which is specified and
implemented by use of XSLT
• All elements in the EQN model can be directly mapped to jEQN
classes, except for Terminal and Fork nodes that are to be
managed differently
• The jEQN Fork class has been implemented regardless of any
consideration of routing policy of outcoming jobs: a routing
policy has to be specified by use of a specific Router class
• An EQN Fork node is implemented using the following jEQN
classes
 a Fork class
 a Router class, whose routingPolicy is set according to specific
needs (the present version adopts a round robin policy)
TMS'12 Andrea D’Ambrogio 15

16. EQN to jEQN model-to-text transformation
• The EQN Terminal node does not have any corresponding
element in jEQN, so that it has been implemented by use of
the following jEQN classes and links:
 A Source class, where the sourceTerminationPolicy attribute
value is equal to N, being N the number of users of the closed
workload
 an InfiniteServer class, whose serviceTime corresponds to the
thinkTime
 All the incoming edges of a Terminal node in the EQN model are
mapped to the incoming link of the InfiniteServer
TERMINAL NODE
EQN
FINITE
NETWORK
…
SOURCE
(N users)
INFINITE
SERVER
(serviceTime = thinkTime)
TMS'12 Andrea D’Ambrogio 16

17. Example application:overview
• Let us consider an example application dealing with a business
process for checking out orders
• It is supposed that users purchase goods through the following
main steps
1. the user navigates in the provider’s catalog and adds the desired
items to the basket
2. the user clicks the checkout button to complete the order and pay;
3. the user specifies the information needed to pay (i.e., the credit
card number) and to receive the parcel (i.e., address, email contact,
etc.)
4. the system computes the total cost, including shipment fares, and
prepares the bill
5. the process in charge of providing, preparing and shipping the
purchased item is activated
• As regards step 3, it is assumed that payment fails with a
probability equal to 10% (in this case the process terminates)
TMS'12 Andrea D’Ambrogio 17

18. Example application: BP specification
• PyBPMN is used to specify the functional and non-functional
requirements of the BP
• BP is designed as an orchestration of the following services:
 Payment Manager (PM) service, to provide payment services
 Stock Manager (SM) service, to manage the stock and the shipping
of the ordered items
 BillingManager (BM) service, to provide billing services
TMS'12 Andrea D’Ambrogio 18

19. Example application: generation of the UML design model
• At the second step, the PyBPMN-to-UML model transformation
is executed to generate the UML design model
• At the third step, a service discovery is carried out to find a
set of concrete services that match the abstract service
interfaces specified in the PyBPMN
• As a result, the performance characteristics of the candidate
service are available, thus can be included in the UML model
by use of SoaML and MARTE profiles
PurchaseService: PM: PaymentManager BM: BillingManager SM: StockManager
Orchestrator
<<PaStep>>
{hostDemand = ('est', 'mean', (2.5,'ms))
<<PaStep>>
<<PaCommStep>>
checkOut
{hostDemand = ('msr', 'mean', (200,'ms))
msgSize = (250,'KB'),(50,'KB')}
PaymentService <<PaStep>>
<<PaCommStep>>
{hostDemand = ('msr', 'mean', (250,'ms))
msgSize = (2,'KB'),(120,'KB')}
<<PaStep>>
[prob=0.9] <<PaCommStep>>
{hostDemand = ('msr', 'mean', (300,'ms))
msgSize = (50,'KB'),(100,'KB')}
[prob=0.3]
Shipping
Billing Service
Service
TMS'12 Andrea D’Ambrogio 19

20. Example application: generation of the peformance model
The performance
prediction is carried
out by first generating
a set of EQN
performance model
that corresponds to
the UML model
representing the
candidate
configurations
TMS'12 Andrea D’Ambrogio 20

21. Example application
• The performance prediction is concluded by executing the jEQN
code in order to obtain the performance indices of interest
To validate the results, a LQN
model has been generated for
the example case study.
TMS'12 Andrea D’Ambrogio 21

22. Conclusions
• This paper has introduced a model-driven method to
automate the performance prediction of BPs
• The method makes use of:
 PyBPMN, to specify the functional/non functional BP
requirements
 UML (with MARTE/SoaML annotations) to specify the design
model
 EQN formalism, to specify the BP performance model
 jEQN language, to implement/execute the performance model
and yields the performance indices of interest
• The method founds on model-driven standards to automate
model building
• The proposed contribution has been integrated into an
already available method for the QoS prediction of BPs,
which has been used to validate the approach
TMS'12

23. Backup Slides
TMS'12

24. BPMN extension process
TMS'12

25. BPMN: Business Process Modeling Notation
The Business Process Modeling Notation (BPMN) is a standard for
the high-level specification of business processes
TMS'12

26. PyBPMN extension details
Workload
characterization
Performance/reliability
characterization
TMS'12