CS565 - Business Process & Workflow Management Systems Business Process Modelling CS 565 - Lecture 2 20/2/17 1
Business Process Lifecycle Enactment: Operation Monitoring Maintenance Evaluation: Process mining Analytics/Warehousing Administration & Stakeholders Configuration: System selection Implementation Test & Deployment Design: Business Process Identification & Modelling Analysis: Validation Simulation Verification CS 565 - Lecture 2 20/2/17 2
Business Process Modelling n The model of a BP can be described via a specific language and be specified through BP modelling tools (part of a BPMS) n Can be performed at different levels: gorganizational (coarse-grained, textual forms) goperational (fine-grained, semi-structured/formal models) n Explicit representation: gusually through graphical notations gideal for internal communication between stakeholders -> flexibility 3
Business Process Modelling n Various types of languages have been proposed: gprocedural: The procedural aspects determine the order of steps (tasks, events, and gateways) that are needed to achieve the relevant process goals. This is comparable with algorithms or operating instructions (Petri Nets, BPMN, BPEL) gdeclarative: processes are based on declarative elements like complex decisions, relationships between variables, or data constraints. This information is expressed using business rules and some kind of functional or logical language. 4
Procedural Business Process Modelling 5
University of Crete, Computer Science Department Declarative Business Process Modelling Source: http://www.slideshare.net/cdc08x/semantical-vacuity-detectionin-declarative-process-mining CS 565 - Lecture 2 20/2/17 6
Declarative Business Process Modelling 7
Declarative Business Process Modelling n Declare is one declarative language g Grounded in Linear Temporal Logic (LTL) g Finite-trace semantics geach constraint is mapped to an LTL formula using operators such as: always, eventually, until, weak until W & next time n Previous example: gc1 (( c) ( d): indicates that tasks c and d cannot be true for the same case gc2 ( c)wa, c3 ( d)wa : second task cannot happen before first occurs (but only first can just occur or no task of the two) gc4 (b ( c d)) : every occurrence of b should be followed by c or d (but not always one-to-one correspondence b can occur multiple times) 8
Formal Business Process Languages n Have unambiguous semantics n Allow for BP analysis n Require some expertise in Mathematics or Computer Science (wrt the formalism used) n Abstract from implementation details n Different formalisms have been employed: g Markov Chains, Queuing Networks, Turing Machines, Transition Systems, Petri Nets, Temporal Logic and Process Algebras 9
Conceptual Business Process Languages n More comprehensive & easy to use n Do not have well-defined semantics n Do not allow for analysis n The respective specifications cannot be executed n Approximate description of the desired behaviour n Examples: Business Process Modelling Notation (BPMN), Event-Driven Process Chains (EPCs), UML Activity diagrams 10
Business Process Execution Languages n Workflow-based languages n Provide the appropriate level of detail for making specifications executable n Precise definition of the desired behaviour n Example: BPEL 11
Flow Charts n Formalised graphic representation of a program/work logic sequence n Sequential flow of actions with no activity breakdown n Characteristics: g Flexibility (various ways for process description) g Easy to use perfect for communication n Drawbacks: g Too flexible g Process boundaries may not be clear gtend to be very big g No difference between main & sub-activities g Hard to navigate (no sub-layers) 12
Flow Chart Example 13
Data Flow Diagrams (DFDs) n Show flow of data/information from one place to another one n Link processes to data stores & indicate their relation to users and outside world n Describe what the process will do but not how n Used for structured analysis n Characteristics: gcomprehensible, verifiable, easy to draw & amend, process breakdown n Drawbacks: only flow of data is represented 14
DFD Example 15
Role Activity Diagrams (RADs) n Graphic view of process from perspective of roles n Focus on roles responsibility & their interactions n Roles include organisational functions, sw systems, customers & suppliers n Characteristics: g Useful in communication g Easy & intuitive to use and understand g Detailed process view g Activity parallelization n Disadvantages: g Business objects exclusion gno process decomposition 16
Role Activity Diagrams (RADs) 17
Role Interaction Diagrams (RIDs) n Resulted from combination of RADs & object interaction diagrams n Matrix used to connect activities with roles n Horizontal lines indicate human/role interactions n Characteristics: g Intuitive to understand geasy to use g Well-definition of responsibilities g Activity breakdown n Drawbacks: gtend to be messy, hard to build & update, no I/O modelling 18
RID Example 19
Integrated Definition for Function Modelling (IDEF) n Family of methods to address modelling needs of an enterprise n For BP modelling, IDEF0 is used: gidef0: Structural graphical representation Shows high-level activities & their I/O, control & mechanisms Process decomposition Characteristics: suitable for implementation as computer sw, quick mapping to high-levels due to hierarchical structure Drawback: just activity sequencing can be modelled CS 565 - Lecture 2 20/2/17 20
IDEF0 Example 21
Unified Modelling Language (UML) Diagrams n Object-oriented methods used for modelling n Collection of engineering practices proven successful for large & complex system modelling n Covers both conceptual (BPs & system functions) & concrete elements (programming language classes, DB schemas, sw components) n UML diagrams: g Class diagram: system structure (concepts & relations) g Statechart diagram: states of a class or system g Activity diagram: activities and actions g Sequence diagram: messages sent between set of objects gcollaboration diagram: complete collaboration between objects 22
UML class diagrams n What is a UML class diagram? n UML class diagram: a picture of the classes in an OO system, their fields and methods, and connections between the classes that interact or inherit from each other n What are some things that are not represented in a UML class diagram? n n details of how the classes interact with each other algorithmic details; how a particular behavior is implemented CS 565 - Lecture 2 20/2/17 23
Class Diagrams n class name in top of box g write <<interface>> on top of interfaces' names g use italics for an abstract class name n attributes (optional) g should include all fields of the object n operations / methods (optional) g may omit trivial (get/set) methods but don't omit any methods from an interface! g should not include inherited methods CS 565 - Lecture 2 20/2/17 24
Relationships between classes n n n n n generalization: an inheritance relationship g inheritance between classes g interface implementation association: a usage relationship g dependency g aggregation g Composition aggregation: "is part of" g symbolized by a clear white diamond composition: "is entirely made of" g stronger version of aggregation g the parts live and die with the whole g symbolized by a black diamond dependency: "uses temporarily" g symbolized by dotted line g often is an implementation detail, not an intrinsic part of that object's state CS 565 - Lecture 2 20/2/17 25
Sequence Diagrams A sequence diagram depicts a scenario by showing the interactions among a set of objects in temporal order. Objects (not classes!) are shown as vertical bars. Events or message dispatches are shown as horizontal (or slanted) arrows from the sender to the receiver. CS 565 - Lecture 2 20/2/17 26
UML Sequence Diagram Example 27
Statechart Diagrams A Statechart Diagram describes the temporal evolution of an object of a given class in response to interactions with other objects inside or outside the system. CS 565 - Lecture 2 20/2/17 28
Activity diagrams n Useful to specify software or hardware system behaviour n Based on data flow models a graphical representation (with a Directed Graph) of how data move around an information system [order reject] Receive Order Fill Order [order accepted] Ship Order Close Order Send Invoice Invoice Make Payment Accept Payment CS 565 - Lecture 2 20/2/17 29
Collaboration Diagrams Collaboration diagrams (called Communication diagrams in UML 2.0) depict scenarios as flows of messages between objects: CS 565 - Lecture 2 20/2/17 30
Event Process Chains (EPCs) n Informal notation for representing domain concepts & processes n Not focused on technical realization n Part of a holistic modelling approach called the ARIS framework n Main building blocks: events, functions (low-level of granularity), connectors (process logic) & control flow edges n Framework also includes interaction flow diagrams (high-level view of organisational entities & their interactions) & function flow diagrams (refinement of interaction flow diagrams with interaction ordering & interaction representation via coarse-grained functions) n EPC drawbacks: gverbose & quite complex diagrams gsemi-formal representation -> problems with transformation to executable format 31
EPC Example 32
Business Process Modelling Notation (BPMN) n Based on flowcharting techniques for processes n Graphical BP diagram with flow & connecting objects, swimlanes, and artefacts n Explicitly indicates organisational information n Covers both orchestrations & choreographies n Characteristics: gflexibility (well-structured technique with process breakdown & rich set of control flow constructs) g Ease of use for both inexperienced and expert stakeholders g Understandability g Supports the construction of simulation models 33
BPMN n Drawbacks: gdata Handling (data structures are not covered could be exploited in conditions) g Message flow (two-level hierarchy of swimlanes) g Representation of states g Under-representation of systems gnot all workflow patterns are covered + for advanced patterns, expertise in filling in no graphical information is needed g Redundant constructs (basic wf pattern modelled in 3 ways) g No formal semantics g Minimal support to resource modelling gmissing support for business-specific terms & business rules 34
BPMN Example 35
Enterprise Modeling n Enterprise modeling: description of main constituents, purpose, processes etc. of an organization g a representation of the organization s knowledge about itself n Creating an enterprise model can reveal anomalies, inconsistencies, inefficiencies and opportunities for improvement n Once a model is created, it can be used to share knowledge within an enterprise, to formulate and evaluate changes n Process definitions can be extracted to be input to a workflow management system n Business process support software can query the enterprise model to obtain information CS 565 - Lecture 2 20/2/17 36
Formal Business Process Modeling n A formal approach to enterprise and business process modeling g concepts must be defined rigorously and precisely g use formal methods to analyze, extract knowledge from them and reason about them n Advantages of adopting a formal approach: g can be verified mathematically g can be proven to be self-consistent g can be shown to have or lack properties n Need to establish methodologies for devising formal models of organizations and their processes CS 565 - Lecture 2 20/2/17 37
Recommended Reading n Ruth Sara Aguilar-Saven. Business Process Modelling: Review and Framework. Int. J. Production Economics 90 (2004) 129 149. n M. Ould Business Processes, chapters 1, 2 n Koubarakis & Plexousakis, A Formal Model for Business Process Modeling and Design, Information Systems 27(2002), pp. 299-319. n https://www.youtube.com/watch?v=ufbfiamoygg&list=plra WWpbaj-7JlEV3_BfBLNYdYKrpqoC68&index=2 38