Lecture on Business Process Modeling Techniques

1. Business Process
Modeling
Ang Chen
2007

2. Outline
• Introduction & Motivation
• Process (Control-Flow) Modeling
• Petri Nets (workflow net), Workflow patterns, BPEL
• Process model properties
• Data Modeling
• UML, Entity-Relationship model
• Data model properties
• Assignment (TP)
2

3. What is business
process?
Definition in the Definition in IT
real-world domain
• using business terms in • most time using IT terms, e.g.
natural languages system, user ...
• conventional business rules • precise in the context
• respect law • exchange ideas between end-
user and developers
• not very precis, sometimes • executable somewhere
ambiguous, need • implement real-world BP
interpretations
3

4. Real-world BP
Traditionally, BP has nothing to do with information technology
“A business process is a sequence of activities followed by
individuals in a business to achieve some business goal. Often
these are manual activities executed by employees who play
certain roles in the business in addition to others who are
external to the business: customers, business partners, etc.”
From “what is a business process”.
4

5. Real-world BP
A business process description
1. A customer fills the purchase order form and send it to the company.
2. (Employee of) The company confirm the reception of order.
3. (Employee of) The company check the stock and prepare the
products.
4. (Employee of) The company deliver the products with the invoice.
5. The customer makes the payment.
6. (Employee of) The company collects the payment.
Depending on the underlying business protocol, the payment may
be effected before (deliver against payment) or after (by credit)
the delivery of product.
Example of a “delivery and payment terms” which describe a business
protocol (rule)
5

6. Real-world BP
• Healthcare, patient treatments
• Biological experiment data processing
• Product manufacture process (ERP)
• E-Trading, E-Government
• Financial supply chain (buyer - seller - bank vs.
product - cash - bill - credit)

7. BP in IT domain
Do you remember how to write Use Cases?
• Real-world process vs. BP definition
• The business process should implement the real-world needs
• BP definition describes only a part of real-world process
(where users interact with the computer system)
Objective of IT in BP Management
To make sure (how) the right persons (who) do the right
things (what) at the right moments (when)
7

8. Objective of IT in BPM
Image from openflow
8

9. BP Management UCs
9

10. Workflow Reference Model
Image from WfMC
10

11. BP Modeling Approaches
• Metamodel-based. Only metamodel is specified.
• Metamodel + state-based semantics. Using Petri Net
variances, e.g. Workflow Net.
• Metamodel + service-based semantics. e.g. Web service
composition languages, BPEL.
• Hybrid approach. Metamodel with both state-based and
service semantics.
• Rules-Driven (less popular)
Business process has similar principle with parallel, distributed programming, and
the computation tasks are realized by the collaboration of human and machines.
11

12. Process Metamodel (1)
openflow
• Process, activity,
transition, instance,
workitem etc.
• no formal semantics
• Integrated in Zope
application server
• Python based
• Good interoperability
with Zope products
12

13. Process Metamodel (2)
XPDL’s Process
metamodel:
Process,
ActivitySet,
Activity,
Application,
Transition,
Participant,
Gateway,
Type,
Property,
etc.
13

14. State-based semantics
• Advantages of using Petri Nets for workflow
modeling:
• Formal semantics
• Inductive graphical notation
• Explicit state representation
• Well developed verification techniques and tools
14

15. Case Study
• To compute the price, the
shipping price is needed
receive • To schedule the
order production, the shipping
date is needed
• To send the invoice to
client, the three tasks
compute organize production should be finished
price shipping scheduling • Tasks are accomplished by
different companies or
departments
• Used data:
send • Order
• Shipping Info
invoice • Schedule
• Price
• Invoice
15

16. Petri Nets Model
16

17. Remarks of modeling
with PN
• The PN elements can be interpreted differently
while modeling business process
• Transitions: Event, Action, Service interaction
• Places: Information holder, List, Database, etc.
• Tokens: Object, information, physical entity, reference,
etc.
• However, similar to logical formula, the properties of
PN model are valid for all the interpretations
(independent of domain)
17

18. Workflow Net
WF-net (workflow net) defined by W.M.P. van der Aalst
A Petri net PN=<P,T,F> is a WF-net if and only if:
• there is one source place i∈P that the pre-set(i) = ϕ
• there is one sink place o∈P that the post-set(i) = ϕ
• every node x∈P∪T is on a path from i to o
• A WF-net has one input place (i) and one output place (o) because any
case handled by the procedure represented by the WF-net is created
when it enters the WFMS and is deleted once it is completely handled
by the system, i.e., the WF-net specifies the life-cycle of a case.
• The third requirement is to avoid dangling tasks and/or conditions
which do not contribute to the processing of cases.
18

19. Workflow Patterns
• Proposed by Van Der Aalst. Categorized into several
perspectives
• Control: flow of cases (instances)
• Data: data and information processing
• Operation: interactions with human and external systems
• Resources: modeling human and machine workforce
• About 20 patterns for the control-flow perspective.
19

20. Control Flow Patterns
• Basic constructs
• AND, OR, JOIN, SPLIT
• Synchronization and Merge
• Cycle and termination
• Multi-Instances
• Cancellation
20

21. invalid!
for a complete explanation with
flash animations, see:
www.workflowpatterns.com
21

22. BPEL brief introduction
• Business Process Execution Language: combined XLANG
from MS and BPFL from IBM. Actual called “WS-BPEL”
• A web service composition language. Variables are used to
pass values between web services
• The states of instances are distributed in differences
machines
• The engine of BPEL invokes web service and receives
service calls according to the BPEL definition
BPEL specifications from IBM: link
22

23. BPEL (2)
• Totally based on Web service specifications
• BPEL -> Web service -> XML schema -> XML
• Control flow: <flow>, <sequence>, <pick>, <while>
…
• Activity: <invoke>, <receive>, <wait> …
• Links: <link>, <source>, <target>
• Participant: <partnerLink>, <role>
• Data: <variable>, <assign>, <messages>
23

24. BPEL (3)
• <flow>: AND split; <sequence>: sequence; <pick>: OR split;
• <invoke>: call web service; <receive>: blocking & waiting
callback;
• <wait>: wait a condition;
• <link>: dependence link;
• <partnerLink>: web service of partner;
• <messages>: schema definition of exchanged message.
For more information for the relationship between workflow patterns and
BPEL, see: “Pattern Based Analysis of BPEL4WS”, by Petia Wohed et al.
24

25. Case Study
•<partnerLinks>
•<partnerLink name=quot;purchasingquot; … />
• <partnerLink name=quot;invoicingquot; …/> receive
•<partnerLink name=quot;shippingquot; …/> order
•<partnerLink name=quot;schedulingquot; …/>
•</partnerLinks>
•<sequence> compute organize production
•<receive…”Order”/> price shipping scheduling
•<flow>
•<sequence> …”computPrice”</sequence>
•<sequence> …”shippping” </sequence>
•<sequence>…”schedule” </sequence> send invoice
•</flow>
•<reply…”Invoice”/> This process has 3 parallel activities.
•</sequence> It receives an Order and reply an Invoice
to the caller (a client)
25

26. BP Properties
• Deadlock free, Soundness
• No cyclic-dependencies
• Each input case should have a final output somewhere
• No hanging tasks. E.g. when a case is finished, all
related tokens should be removed
• Efficiency & Performance (related to BP design): no
unnecessary, repetitive work for users, e.g. fill the same
information (form) for several times.
26

27. Data Modeling
Data modeling includes data definition and
manipulation. Data model is the basis of
business process.
• Entity-Relationship Model
• Relational Model
• Service Data Object
27

28. Entity-Relationship
Model
• Originally proposed by Peter Chen in 1976. Paper “The Entity-
Relationship Model--Toward a Unified View of Data”.
• The most-used conceptional modeling tool. Many variances exist.
• Conference site: http://www.conceptualmodeling.org/
• Based on a very simple graphical notation (ER Diagram)
artist performs song name
Entity Relation Entity Attribute
28

29. Entity & Attribute
• Entity: a concept about which information is collected
• Attribute: descriptive properties of an entity
• Attribute Type: the domain of an attribute
• Entity Type: collection of entities that all have the same attributes
• Entity Set: collection of entities of a particular entity type
• Key attributes of an Entity Type: the attributes used to uniquely
determine each entity in an entity set. The attributes set is called a
superkey
• Candidate key: the minimum superkey of an entity type. The primary
key of the entity type is selected among all possible candidate keys.
29

30. Relationship
• (An instance of) Relationship: association among two or
more entities.
• Relationship Type: the collection of similar relationships
• Degree of a relationship: the number of entity types that
participate in the relationship type.
• Role of an entity in a relationship
• Relationship attributes: properties of a relationship
• Relationship does not have key attributes, it’s identified by its
participants’ identities
30

31. ER Model
• ER variances often differ from the following points:
• The degree of the relationship: unary, binary, or
more
• The type cardinality constraints and participation
constraints
• The direction of relationship
• Whether a relation can have attributes or not
31

32. Degree of relationship
1
Unary
Employee mananges
M
1 M
Binary Manager mananges Employee
M 1
Ternary Book ownership Store
1
Person
A relationship with degree >2 can be
decomposed into several binary
relationships
32

33. Cardinality &
Participation Constraints
• Cardinality constraints: Minimum, Maximum
cardinality e.g. (M..N - 1..N)
• Participation constraints: (1..N - 1..N)
Mandatory e.g. (0..N - 0..N),
Optional,
• The two constraints sets may have conflicts or
overlaps
• In case of conflicts, the ER model is not structurally valid.
33

34. Participation
Constraints
Graphical notations optional
mandatory
1 M There is maximum one manager to manage
Manager mananges Employee the employees.
It is possible that there are no employees.
1 M
There must have a manager to
Manager mananges Employee manage the employees.
It is possible that there are no
employees.
34

35. Unary relationship
self self
mananges mananges
1 1
1
1 1 1
Employee mananges
Employee mananges
M
1
M
• Everybody is an employee, but there is an employee who
manages others.
• The same time, he manages himself.
• on the right, 1-1 with optional-mandatory constraints is not
valid
35

36. Binary relationship
1 M
Manager mananges Employee
what is the possible relationship
between the manager and the
department?
?? M
1
Department member of
• An acyclic path containing all binary
relationships is always structurally valid
• In an cyclic path, there are risks that it is not
structurally valid
36

37. Enhanced ER model &
UML
• They can be considered as ER models with extended
semantics and constraints
• EER: Specialization/Generalization, Aggregation
• UML: Inheritance(Generalization), Composition,
Aggregation. For OO design.
37

38. Specialization/
Generalization
• subtypes and supertypes of entities
• cardinality constraints between supertype:subtype is 1:0
• Supertype: Employee
ID
• Subtype: Hourly, Salaried
Employee
Date • Subtypes inherit all the attributes of
Hired
Name the supertype
1
• The primary key of the supertype and
subtypes are identical
IS-A
• An occurrence of the Employee needs
not have an occurrence of Salaried
Hourly Salaried
nor Hourly.
• An occurrence of the Salaried or
Hourly MUST HAVE an occurrence of
Wage Salary the supertype entity Employee.
38

39. Specialization
Constraints
ID
Date
We see that:
Employee
Hired • An occurrence of “Hourly” or “Salaried”
Name 1 entity must have an occurrence of
“Employee” entity
IS-A • “Hourly” and “Salaried” entity types inherit
the attributes from entity type “Employee”
Hourly Salaried
But:
• Does an occurrence of “Employee” entity
must have an occurrence of “Hourly” or
Wage Salary “Salaried” entity?
• Does an occurrence of “Employee” entity can
have both occurrences of “Hourly” and
“Salaried”?
39

40. Specialization
Constraints
• Completeness Constraints
• Total/Partial Specialization. An occurrence of a supertype entity must/may
have a corresponding subtype occurrence (double line)
• Disjointness Constraints
• Overlap rule(total/partial). An occurrence of a supertype must/may have
more than one subtype occurrence (mark “O”)
• Disjoint rule(total/partial). An occurrence of a supertype must/may have
exactly one subtype occurrence (mark “D”)
• Multiple Inheritance
40

41. Examples
ID
ID
Date
Employee Date
Hired Employee
Name Hired
1
Name
1
O
1 1 D
1 1
Hourly Salaried
Hourly Salaried
Wage Salary
Wage Salary
41

42. Integrity Constraints
• These constraints are used to valid business (or
domain) rules
• Entity Integrity (Uniqueness Integrity): each instance of an
entity type must have a unique identifier that is not null
• Referential Integrity: relationship has references to the
participant entities, e.g. existence dependency
• Domain Constraint: e.g. range, format, null or not null of
values etc.
• Operational Constraint: constraints (e.g. business rules )
should be respected during the data manipulation
42

43. UML Class Diagram
• Aggregation: has-a relationship, between object and
component parts. Filled diamond side means the whole side.
• Subclasses (specialization/generalization)
• blank triangle for disjoint, filled triangle for overlap
• Weak entity: qualified association
• Relationship types are associations
• Relationship instances are links, using (min..max) for
cardinality constraints
• Attributes and domains are merged in the box
43

44. ER vs. UML
Department
Name Department Name
1 Abstract class has name in italics
1
member
0..*
of Employee Department
M ID Name
ID Name
1
Date DataHired
Employee 0..*
Hired
Name Employee
1 ID
Hourly Salaried Name
O Wage Salary DataHired
Hourly Salaried
Hourly Salaried
Wage Salary
Wage Salary
Which UML model the ER model corresponds?
44

45. Data Model Properties
• Structurally valid: there are no contradictions and
conflicts in the model itself
• Semantically valid: the designed model corresponds the
domain problem, e.g. a student must finish at least 20
credits per year
• Integrity constraints: rules & constraints should be
respected during the evolution of data instances
• Functional dependency (in relational model): why a
relational schema is better than another? Optimization
45

46. Reference: ER &
Relational Model
• http://portal.acm.org/citation.cfm?id=320440
• http://www.siue.edu/~dbock/cmis450/4-eermodel.htm
• http://dbis.ucdavis.edu/courses/165A-SQ07/Handouts/ermodel.pdf
• http://dbis.ucdavis.edu/courses/165A-SQ07/Handouts/relmodel.pdf
• http://dbis.ucdavis.edu/courses/165A-SQ07/Handouts/integrity.pdf
46

47. Assignment
• Modeling the business processes of fundable.com
and zopa.com (social fundraising)
• http://fundable.com/ and http://zopa.com
• Data model
• Control-flow model
• Connection between Data and Control models
• An individual report in 2 weeks