Summary Business Process Integration (BPI)
2019-2020
Introduction to Business Process Modeling (UML) 1
WHY: 1
WHAT: 1
WHO: 1
HOW: 2
UML modeling: 2
Use case diagram (user view): 2
Class diagram (structural view): 5
Sequence diagram (behavioural view): 9
Activity diagram (behavioural view): 10
Lecture 1: Business Process Integration 11
Lecture 1b: The world of e-Business 11
Lecture 2: e-Business Relationships 14
Lecture 3: e-Business Technological Infrastructure 19
Lecture 4a: e-Business Networks 24
Lecture 4b: Enterprise Application Integration (EAI) 28
Lecture 5: e-Business Integration 33
, Introduction to Business Process Modeling (UML)
1. WHY:
Why we need business process models: modeling is a way of communication; a model is a communication
tool.
The aim of UML is to communicate the story via UML to your stakeholders. Therefore, you need to be concrete
and not apply too much simplification.
People within an organization often use different languages:
● Business: KPI, budget, ROI (cost), customer satisfaction, usability
● IT: functionality, use cases, release, bugs, maintenance, scalability, budget (revenue)
2. WHAT:
What is a model: abstract representation of the real world. It
reduces complexity as it only represents necessary details.
Collaborative business process:
The client’s and supplier’s business processes are both private
but aligned through collaborative activities.
A collaborative process spans multiple enterprises and creates
value for them.
● Collaborative process = a process with implicit
behaviour and interactions between multiple business
entities with different roles.
● Collaborative activities = actions performed by the
participating entities in response to the messages they
receive from other participating entities.
3. WHO:
Who are involved in UML: service stakeholders such as customers,
service providers, business partners, system operators, etc.
1
, 4. HOW:
A modeling method consists of:
1. Modeling language = a language (usually graphical) that
the method uses to express the design. UML is NOT a
method.
2. Process = a set of guidelines/steps of how to do the
design (e.g. Rational Unified Process [RUP]). RUP
building blocks are visualized in the image on the right.
UML modeling:
Relevant UML models for this course include (1) Use case diagrams; (2) Class diagrams; (3) Sequence diagrams;
(4) Activity diagrams.
1. Use case diagram (user view):
Link for a good explanation on use cases: https://francescolelli.info/tutorial/developing-uml-diagrams/
Use cases: a use case is a set of scenarios tied together by a common user goal.
Any use case has a primary scenario (all-goes-well) and other scenarios where things are going wrong or
alternatively than the primary scenario. A scenario is a sequence of steps describing an interaction between a
user and a system.
A use case diagram visualizes the functionality of the system in transactions (use cases) between actors and
the system. Actors perform use cases (i.e. roles), connected by links. Use cases may use other use cases
connected to each other by ‘’include’’ relationships.
2
, Use case diagram example:
● Alternative 1: Regular customer
○ 1a: system displays current shipping info, pricing info, and last four digits of credit card info
○ 1b: customer may accept or override these defaults
■ Return to primary scenario at step 6
● Alternative 2: Authorization failure
○ 2a: at step 6, system fails to authorize credit purchase
■ Allow customer to re-enter credit card info and re-try
Reuse of use cases could be done in the following way:
<<include>> relationship denotes the inclusion of the behavior described by another use case. It shows
dependency between a base use case and an included use case.
Every time the base use case is executed, the included use case is executed as well (i.e. a base use case
requires the included use case in order to be complete). Here, the dashed line points from the base use case
towards the included use case. An example could be “log in” as the base use case and “verify password” as the
included use case (everytime a customer logs in, the banking app will automatically verify the password). This
log in won’t be complete unless the password is verified. Another example is visualized below.
Generalization denotes a specialized case of achieving the same goal, for capturing alternative scenarios. For
example, when a payment is made, it can either be made from a checking account or from a savings account.
Here, “make payment” is a general use case a nd “pay from checking” and “pay from savings” are specialized
use cases. Each specialized use case adds something more on its own. Generalizations apply on use cases as
well as on actors (e.g. customer = general use case; new customer and returning customer = specialized
actors)Another example is visualized below.
3
2019-2020
Introduction to Business Process Modeling (UML) 1
WHY: 1
WHAT: 1
WHO: 1
HOW: 2
UML modeling: 2
Use case diagram (user view): 2
Class diagram (structural view): 5
Sequence diagram (behavioural view): 9
Activity diagram (behavioural view): 10
Lecture 1: Business Process Integration 11
Lecture 1b: The world of e-Business 11
Lecture 2: e-Business Relationships 14
Lecture 3: e-Business Technological Infrastructure 19
Lecture 4a: e-Business Networks 24
Lecture 4b: Enterprise Application Integration (EAI) 28
Lecture 5: e-Business Integration 33
, Introduction to Business Process Modeling (UML)
1. WHY:
Why we need business process models: modeling is a way of communication; a model is a communication
tool.
The aim of UML is to communicate the story via UML to your stakeholders. Therefore, you need to be concrete
and not apply too much simplification.
People within an organization often use different languages:
● Business: KPI, budget, ROI (cost), customer satisfaction, usability
● IT: functionality, use cases, release, bugs, maintenance, scalability, budget (revenue)
2. WHAT:
What is a model: abstract representation of the real world. It
reduces complexity as it only represents necessary details.
Collaborative business process:
The client’s and supplier’s business processes are both private
but aligned through collaborative activities.
A collaborative process spans multiple enterprises and creates
value for them.
● Collaborative process = a process with implicit
behaviour and interactions between multiple business
entities with different roles.
● Collaborative activities = actions performed by the
participating entities in response to the messages they
receive from other participating entities.
3. WHO:
Who are involved in UML: service stakeholders such as customers,
service providers, business partners, system operators, etc.
1
, 4. HOW:
A modeling method consists of:
1. Modeling language = a language (usually graphical) that
the method uses to express the design. UML is NOT a
method.
2. Process = a set of guidelines/steps of how to do the
design (e.g. Rational Unified Process [RUP]). RUP
building blocks are visualized in the image on the right.
UML modeling:
Relevant UML models for this course include (1) Use case diagrams; (2) Class diagrams; (3) Sequence diagrams;
(4) Activity diagrams.
1. Use case diagram (user view):
Link for a good explanation on use cases: https://francescolelli.info/tutorial/developing-uml-diagrams/
Use cases: a use case is a set of scenarios tied together by a common user goal.
Any use case has a primary scenario (all-goes-well) and other scenarios where things are going wrong or
alternatively than the primary scenario. A scenario is a sequence of steps describing an interaction between a
user and a system.
A use case diagram visualizes the functionality of the system in transactions (use cases) between actors and
the system. Actors perform use cases (i.e. roles), connected by links. Use cases may use other use cases
connected to each other by ‘’include’’ relationships.
2
, Use case diagram example:
● Alternative 1: Regular customer
○ 1a: system displays current shipping info, pricing info, and last four digits of credit card info
○ 1b: customer may accept or override these defaults
■ Return to primary scenario at step 6
● Alternative 2: Authorization failure
○ 2a: at step 6, system fails to authorize credit purchase
■ Allow customer to re-enter credit card info and re-try
Reuse of use cases could be done in the following way:
<<include>> relationship denotes the inclusion of the behavior described by another use case. It shows
dependency between a base use case and an included use case.
Every time the base use case is executed, the included use case is executed as well (i.e. a base use case
requires the included use case in order to be complete). Here, the dashed line points from the base use case
towards the included use case. An example could be “log in” as the base use case and “verify password” as the
included use case (everytime a customer logs in, the banking app will automatically verify the password). This
log in won’t be complete unless the password is verified. Another example is visualized below.
Generalization denotes a specialized case of achieving the same goal, for capturing alternative scenarios. For
example, when a payment is made, it can either be made from a checking account or from a savings account.
Here, “make payment” is a general use case a nd “pay from checking” and “pay from savings” are specialized
use cases. Each specialized use case adds something more on its own. Generalizations apply on use cases as
well as on actors (e.g. customer = general use case; new customer and returning customer = specialized
actors)Another example is visualized below.
3
