Business process modeling
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Business Process Modeling PowerPoint PPT Presentation


  • 112 Views
  • Uploaded on
  • Presentation posted in: General

Business Process Modeling. Enterprise modeling : description of main constituents, purpose, processes etc. of an organization a representation of the organization’s knowledge about itself

Download Presentation

Business Process Modeling

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Business process modeling

Business Process Modeling

  • Enterprise modeling: description of main constituents, purpose, processes etc. of an organization

    • a representation of the organization’s knowledge about itself

  • Creating an enterprise model can reveal anomalies, inconsistencies, inefficiencies and opportunities for improvement

  • Once a model is created, it can be used to share knowledge within an enterprise, to formulate and evaluate changes

  • Process definitions can be extracted to be input to a workflow management system

  • Business process support software can query the enterprise model to obtain information

HY 565 - Lecture 2


Business process modeling1

Business Process Modeling

  • A formal approach to enterprise and business process modeling

    • concepts must be defined rigorously and precisely

    • use formal methods to analyze, extract knowledge from them and reason about them

  • Advantages of adopting a formal approach:

    • can be verified mathematically

    • can be proved to be self-consistent

    • can be shown to have or lack properties

  • Need to establish methodologies for devising formal models of organizations and their processes

HY 565 - Lecture 2


Business process modeling2

Business Process Modeling

  • A formal model for Business Process Modeling and Design [Koubarakis & Plexousakis, 2002]

    • a goal-oriented methodology for business process design

    • founded on the situation calculus

    • process modeling using ConGolog, a concurrent logic programming language

    • outcome is a detailed formal specification of a business process that achieves the specified objectives

    • developed as a set of submodels that capture the business process from various viewpoints

    • formal verification using AI techniques

HY 565 - Lecture 2


Modeling concepts

Modeling Concepts

  • An enterprise model comprises 5 interconnected submodels used to describe formally different aspects of an organization:

    • organizational submodel: describes the actors in the enterprise, their roles, their responsibilities and their capabilities

    • objectives and goals submodel: describes what the enterprise and its actors are trying to achieve

    • process submodel: describes how the goals are to be achieved

    • concepts submodel: describes non-intentional entities

    • constraints submodel: describes factors limiting what the enterprise and its components can do

HY 565 - Lecture 2


Modeling concepts1

Modeling Concepts

  • Basic tool: a first-order logical languageL

    • symbols ofL include:

      • parentheses,

      • a countably infinite set of variables,

      • quantifiers (universal, existential),

      • equality,

      • sentential connectives (negation, conjunction, disjunction, implication, equivalence)

      • function symbols (including constants)

      • predicate symbols

  • Notational convention: predicate and function symbols start with uppercase letters; variables with lowercase

HY 565 - Lecture 2


Modeling concepts2

Modeling Concepts

  • A set of sentences of L makes up a first-order theory

  • Use of a first-order logical languages provides the ability to represent incomplete enterprise knowledge

    • e.g., this job can be assigned to person A or person B

  • Incomplete knowledge is impossible to represent in other enterprise knowledge frameworks (e.g., those based on entity-relationship modeling or UML diagrams)

  • Reasoning with incomplete knowledge is important for organizational planning

HY 565 - Lecture 2


Organizational submodel

Organizational Submodel

  • Main concepts: actor and role

    • actor is an intentional entity, i.e., has some idea or purpose that guides its actions

    • used to model (groups of) people, software / hardware systems that are capable of executing certain activities

    • distinguished into human and automated

    • an organizational role involves a set of responsibilities and actions carried out by actors

    • organizational roles can have different forms:a unique functional role (e.g., Systems Department),a unique functional position (e.g., Managing Director),a rank or job title (e.g., Associate Professor),a replicated functional group (e.g., Department), a replicated functional position (e.g., Director),a class of persons (e.g., Customers) or an abstraction (e.g., Progress Monitoring)

HY 565 - Lecture 2


Organizational submodel1

Organizational Submodel

  • Role instances are acted out by actors or groups of actors

  • Different actors can play different roles at different points in time

  • Many instances of the same role can be active at any point in time

  • In L we use unary and binary predicates to denote these concepts. Also need axioms capturing their semantics

  • Example:

    HumanActor(John), HumanActor(Mary)

    Role(Tutor), Role(Secretary)

    PlaysRole(John,Tutor), PlaysRole(Mary, Secretary)

    x (Actor(x)  HumanActor(x)  AutomatedActor(x))

  • HY 565 - Lecture 2


    Objectives and goals submodel

    Objectives and Goals Submodel

    • An enterprise goal is a desired state of affairs

      • e.g., “all customer requirements are answered within two days”, “profits must be maximized”

    • Goals are associated with components of other submodels:

      • goals are assigned to roles; they become responsibilities of roles and the actors playing the roles (organizational submodel)

      • the purpose of a process is the achievement of one or more goals (process submodel)

      • goals refer to enterprise entities (concepts submodel)

    • Capturing goals explicitly allows expressing “what”,“why” and “who”, i.e., permits studying the organization from an intentional point of view

    HY 565 - Lecture 2


    Objectives and goals submodel1

    Objectives and Goals Submodel

    • Organizing goals

      • Goals can be reduced into alternative combinations of subgoals by using AND/OR goal graphs

      • E.g., the goal “sales targets are achieved” can be AND-reduced to “sales target for product A are achieved” and “sales target for product B are achieved”

    • An organizational objective is a goal that does not result from goal reduction, i.e., a top-level goal, or “an end in itself and not a means serving some higher-level end”

    • Goals can conflict with each other: goals are said to conflict if they cannot be satisfied simultaneously

    • Goals can also influence positively or negatively other goals

    • Such interactions between goals must be defined explicitly

    HY 565 - Lecture 2


    Objectives and goals submodel2

    Objectives and Goals Submodel

    • Defining goals formally:

      • High-level objectives may be difficult to formalize; they can be described informally and stepwise reduced to more concrete and formal goals

      • Concrete goals can be formalized as sentences of L

      • Example: the goal “enquiries are answered by a member of staff as soon as they are received” can be formalized as the sentence:

        (a)(e)(x)(s)(s’) (Staff(a)  Enquiry(e)  Action(x)  Situation(s)  Situation(s’)  Received(e,a,s)  s’=Do(x,s)  Answered(e,a,s’)

        s’=Do(x,s) means that s’ is the situation resulting from the execution of action x in situation s

    HY 565 - Lecture 2


    Process submodel

    Process Submodel

    • Main concepts:

      • Situtations are states of affairs

      • Changes occur in situations as results of actions

      • Actions can be primitive or complex

      • Actions are formally specified (situation calculus and ConGolog)

      • Categories of actions: causal, knowledge-producing, exogenous

      • A business process is a network of actions performed in the context of one or more organizational roles in pursuit of some goal

    HY 565 - Lecture 2


    Process model

    Process Model

    • Based on the Situation Calculus:

      • Actions are denoted by 1st-order terms of the form f(args) where f is a function symbol and args is a list of 1st-order terms

      • Relations whose truth values may differ from one situation to another are called fluents

      • Fluents are denoted by predicate symbols having a situation term as their last argument

      • Functional fluents are used to express functions whose denotation varies from one situation to another

    HY 565 - Lecture 2


    Process model1

    Process Model

    • Primitive actions are specified by expressions of the form:

      action a

      precondition f1

      effect f2

      endAction

      wherea is an actionandf1, f2 are formulas ofL

    • Example:

      actionForwardApp(a1,a2,app)

      preconditionHas(a1,app)

      effectHas(a2,app)  Has(a1,app)

      endAction

    HY 565 - Lecture 2


    Process model2

    Process Model

    • Complex actions may be defined recursively using ConGolog:

      • Primitive actions are actions

      • noOp: special action of doing nothing

      • Sequencing: ifa1, a2 are actions thena1;a2 is the action that consists ofa1 followed bya2

      • Waiting for a condition: iff is a formula ofL thenf? is the action of waiting until conditionf becomes true

      • Non-deterministic choice of action: ifa1, a2 are actions thena1|a2 is the action that consists ofnon-deterministically choosing betweena1 anda2

      • Non-deterministic choice of action parameters: ifa1, a2 are actions thenPx(a1) denotes the non-deterministic choice of parameter x fora1

    HY 565 - Lecture 2


    Process model3

    Process Model

    • Non-deterministic iteration: if ais an action than a*denotes performing a sequentially 0 or more times

    • Conditionals and interation: ifa1, a2 are actions then if f then a1 else a2 defines a conditional and while f do a1 denotes iteration

    • Concurrency: ifa1, a2 are actions thena1||a2 is the action ofexecutinga1 anda2 concurrently

    • Concurrency with priorities: ifa1, a2 are actions thena1>>a2 denotes thata1 has higher priority thana2 anda2 may only execute whena1 is done or blocked

    • Non-deterministic concurrent iteration: if ais an action than a||denotes performing a concurrently 0 or more times

    • Interrupts: ifxis a list of variables, f a formula ofLanda an action, then<x: f a> is an interrupt (when control arrives at the interrupt, action triggers if the condition is satisfied)

    HY 565 - Lecture 2


    Process model4

    Process Model

    • Procedures: can be defined with the construct

      proc b(x) endProc. Procedurecall: b(x)

  • Example:

    proc ProcessApp

    <app: Application(app)  Has(self, app) 

    if AvgMark(app) < 70 then

    for a: Actor(a)  PlaysRole(a, Secretary) do

    SendMessage(self,a,Inform(Unacceptable(app)))

    endfor

    else for a: Actor(a)  PlaysRole(a, Lecturer) do

    ForwardApp(self,a,app)

    endfor

    endif

    >endProc

  • HY 565 - Lecture 2


    Process model5

    Process Model

    • A business process is defined by an expression of the form:

      process id

      purpose goals

      RoleDefs

      endProcess

    • Roles are defined by expressions of the form

      role id

      responsibility resps

      Primitive Action Defs

      Procedure Defs

      endRole

    HY 565 - Lecture 2


    Process model6

    Process Model

    • Example:

      role Tutor

      responsibility …..

      action ForwardApp(a1,a2,app)

      precondition Has(a1,app)

      effect Has(a2,app)  Has(a1,app)

      endAction

      action SendMsg(sender, recipient, msg)

      ….

      endAction

      proc main

      …..

      endProc

      endRole

    HY 565 - Lecture 2


    Process model7

    Process Model

    • In the definition of each role, the business process designer has to specify a ConGolog procedure which defines the dynamics of the role

    • Attaching responsibilities to roles: pseudo-variable self is assumed to range over all actors playing the role inside which the variable appears

    • Different types of actions included in procedures:

      • ForwardApp is a causal action

      • SendMsg is a knowledge-producing action

    HY 565 - Lecture 2


    Concepts and constraints submodels

    Concepts and Constraints Submodels

    • Concepts submodel contains information about enterprise entities, their relationships and their attributes

      • Information in this submodel is formally expressed by sentences ofL

      • Enterprise data are part of this submodel

      • Establishes a conceptual model of the organization and all entities it encompasses

    • The Constraints submodel is used to encode restrictions imposed on enterprise entities

    • Constraints are encoded in the situation calculus and can be static or dynamic

      • E.g., (p)(Accepted(p)  Rejected(p))

    HY 565 - Lecture 2


    A methodology for business process design

    A Methodology for Business Process Design

    • Identify the organizational objectives and goals; initiate goal reduction

    • Identify roles and their responsibilities; match goals with role responsibilities

    • For each role specify its primitive actions, the conditions to be noticed and its interaction with other roles

    • Develop ConGolog procedures local to each role for discharging each role’s responsibilities

    • Verify formally that the ConGolog procedures local to each role are sufficient for discharging its responsibilities

    HY 565 - Lecture 2


    A methodology for business process design1

    A Methodology for Business Process Design

    • Goal identification and reduction

    Number of graduate students is maximized

    Application evaluations are completed quickly

    Initial screening done promptly

    Promising applications forwarded to

    appropriate members of staff

    HY 565 - Lecture 2


    A methodology for business process design2

    A Methodology for Business Process Design

    • Identify roles and responsibilities

      • Role identification:

        • Existing role: Faculty

        • New roles: Tutor and Secretary

      • Responsibility assignments

        • Tutor: do initial screening of applications, forward promising applications to Faculty

        • Secretary: handle all correspondence with applicants, forward applications to Tutor

        • Faculty: evaluate applications a.s.a.p.

    HY 565 - Lecture 2


    A methodology for business process design3

    A Methodology for Business Process Design

    • Specify the internal structure of roles

      • E.g., role Tutor

        • Actions: screen an application (complex) and forward an application (primitive)

        • Conditions to monitor: new application arrives

        • Interactions with other roles: sending a message of type INFORM

    • Specify the dynamics of each role

      • Example in slide 17

      • Similarly for other roles

    • Formal Verification

    HY 565 - Lecture 2


    Formal verification

    Formal Verification

    • Formally verify that each role responsibility is fulfilled and each constraints is maintained by the ConGolog procedures defined for each role

    • Verification is based on a solution to the frame and ramification problems

    • It is determined whether consistency with respect to defined responsibilities and constraints is preserved or violated as a result of process execution

    • Reasoning with process specifications (at design time)

    • Strengthened specifications are proposed so that it can be provably guaranteed that constrains will not beviolated

    HY 565 - Lecture 2


    Formal verification1

    Formal Verification

    • Example:

      Action specification

      action SendOfferLetter(app)

      precondition ( lect) WantsToSupervise(lect,app)

      effect Accepted(app)

      endAction

      Constraint: no applicant can be both accepted and rejected

      (p)(Accepted(p)  Rejected(p))

      The specification does not exclude situations in which Accepted(p) and Rejected(p) are both true.

    HY 565 - Lecture 2


    Formal verification2

    Formal Verification

    • The action specification must be strengthened to exclude such situations

    • A ramification (logical implication) of the constraint and the action specification: Rejected()

    • Strengthened specification

      action SendOfferLetter(app)

      precondition ( lect) WantsToSupervise(lect,app)

      effect Accepted(app)  Rejected(app)

      endAction

    HY 565 - Lecture 2


    Formal verification3

    Formal Verification

    • Ramifications of constraints and process specifications have the following properties:

      • If a ramification of a goal / constraint is known to be unsatisfiable, then the constraint/goal is unsatisfiable

      • Constraint / goal ramifications can reduce the search space for constraint / goal satisfaction

      • Transformations may be applicable to ramifications of goals or constraints but not to the goals or constraints themselves

    • If we have a systematic way of generating ramifications, then the derived ramifications can be used for making the task of meeting the constraints / goals simpler

    HY 565 - Lecture 2


    Formal verification4

    Formal Verification

    • Generating ramifications may require an arbitrary amount of inferencing

    • In general, the problem is intractable (1st-order logic is only semi-decidable)

    • Tractability can be achieved by restricting the class of constraints / goals for which ramifications are sought (e.g. the class of formulas that are conjunctions of atomic predicates)

    • Results exist for binary temporal constraints in prenex normal form (details in the paper)

    HY 565 - Lecture 2


    Summary

    Summary

    • A formal approach to enterprise modeling and business process design using situation calculus and ConGolog

    • Research issues:

      • Implementing support tools

      • Simulating large processes using ConGolog

      • Extend verification techniques to cover all features of ConGolog

    • Suggested readings:

      • M. Ould “Business Processes”, chapters 1, 2

      • Koubarakis & Plexousakis, “A Formal Model for Business Process Modeling and Design”, Information Systems 27(2002), pp. 299-319.

    HY 565 - Lecture 2


  • Login