THE BUSINESS PROCESS MODELLING NOTATION (BPMN)

Student Names: Evance E Kahabi ID 0177AAAA1109 Sanjar Tursunov ID 0092SNSN0809 Wanderi Muthigani ID 0016AAAA0410 Lecturer: Richard Dybowvski

Introduction
A business process modelling focus on describing activities within the enterprise and how they interact with the resources in the business so that the current process may be analysed and improved to achieve a goal. As explained by Penker (Eriksson & Penker, 2000) a business process model may have six different reasons to be created, which are:       To understand the key mechanisms of an existing business; To orient the creation of suitable information systems that support the business; To implement improvements in the current business; To show the structure of an innovated business; To experiment new business concepts; To identify business elements not considered part of the core, this could be delegated to an outside supplier.

The increasing interest in business process modeling has resulted in the appearance of various Business Process Modeling Languages (BPMLs). Now days, there are several notations that can be used for business process modeling (List & Korherr, 2006) such as: UML 2.0 Activity Diagram (OMG, 2005), Business Process Modeling Notation (OMG, 2006), Event Driven Process Chain (EPC) (Scheer, 1999), Integrated Definition Method 3 (IDEF3) (Mayer & Perakath, 1995). These languages express certain aspects of processes, for example, activities and roles, and address different application areas. The business modeler describe the whole process within the entire enterprise by using specific notations and tools (Eriksson & Penker, 2000), through this it is also important to know that internal business customers do not need an expert in these BPMLs, they only need to understand the outcome of the modeling, particularly, they should know how to read business process diagrams. And therefore, before the selection of an appropriate business modeling language to be used, the modelers and designers should observe the type of process being modeled and the purpose for which the modeling is being done (Russell et al, 2006b).

A comparison of BPMN with UML activity diagrams. When comparing the modelling elements of UML and BPMN, many similarities become obvious. There are also differences, especially regarding the modelling of data objects, events, or the data flow between process steps. For example, if data elements are included in a BPMN model, which is essential for most business processes, they have to be separated from the control flow (OMG 2006). Above all, BPMN generally contains fewer graphical elements than UML and instead uses variations of them to support similar process patterns. Example, BPMN uses similar elements to model events of different types or to depict parallel, exclusive, and inclusive gateways. Especially this reduced set of graphical constructs in combination with the clear separation of control and data flow in BPMN are often emphasized in literature and used as a rationale to claim its better usability for business users (Weske 2007, White 2004). As some constructs of BPMN can be regarded as overloaded, the clarity of the language might be reduced (Wand & Weber 1993) this is due to the fact that these elements have some negative impacts to BPMN. Therefore, it has to be validated if the

claim of better usability, due to the reduced set of graphical constructs, outweighs the reduction of expressive power. Russell described the suitability of UML Activity Diagrams for business process modelling by using Workflow Patterns (Russell et al., 2006b) as an evaluation framework. The pattern evaluation shows that UML Activity Diagrams is not suitable for representing all aspects of this type of modeling. It gives support for control-flow and data perspective allowing most of the constructs to be captured. However, it is absolutely limited in modeling resource-related or organizational aspects of business process. These limitations are shared with most of the other BPMLs, showing the emphasis that has been placed on the control-flow and data perspectives in these notations. White (White, 2004) explains whether two modeling notation, BPMN and UML Activity Diagrams, can graphically represent the control flow workflow patterns. White examined 21 workflow patterns and observed that they could adequately model most of them. Both notations provide similar solutions for most of the patterns indicating how close the notation is in their presentation. The similarities in the two diagrams are described by the fact that both were created to solve the problem of the diagramming of procedural business processes. Some differences are due to the fact that they have different target users of diagrams: business people for BPMN, and software developer for UML 2.0.

Workflow Patterns Workflow patterns has described into four perspectives by Russel et al (Russell et al, 2006a): data, control-flow, exception handling and resource. The CONTROL-FLOW perspective captures aspects related to control-flow dependencies. Originally twenty patterns were proposed for this perspective, but in the latest revision this has grown to forty-two patterns. This perspective includes patterns for Basic Control Flow, Advanced Branching and Synchronization, Multiple Instance, Cancellation and Force Completion, Iteration, Termination and Trigger. The DATA perspective represents the visible definition of data elements and use, information passing, data transfer and interaction with other perspectives. Data perspective includes patterns for Data visibility, Internal Data Interaction and External Data Interaction, Data Transfer Mechanisms and Data based Routing. The resource perspective captures the various ways in which resources are represented and utilized in workflows. This perspective includes patterns for Creation, Push, Pull, Detour, Auto-Start, Visibility, and Multiple Resource. Finally the patterns for the exception handling perspective deal with the various causes and the resultants actions need to be taken as a result of exception occurrences. All these patterns range from very simple to very complex aspects of business process models. Looking at the main differences between BPMN and UML activity diagrams the following would be described from the research we have gone through. There are differences in Minor lexical and differences in nomenclature, example the symbols used for AND-split and AND-join differs between BPMN and UML activity diagrams and this it has described in our processes.

BPMN has a notion of the so called event-driven choice while Unified Modeling Language activity diagram does not have. Business Process Modeling Notation probably has seemed to have got this feature from BPEL which provides a construct called PICK with the same intended semantics. Unified Modeling Language activity diagrams rely on signals whereby Business Process Modeling Notation relies on events. Some perceptions consider that signals are a lower-level concept than events. Also, Business Process Modeling Notation offers zoology of predefined event types, whereas Unified Modeling Language activity diagrams does not specify any signals with special semantics a priori although they are all user-defined. Business Process Modeling Notation gives a larger number of control-flow constructs that is gateways as compared to Unified Modeling Language activity diagrams. In particular Business Process Modeling Notation has OR-splits, OR-joins, and so called complex gateways. The OR-split and especially the OR-join are basically taken from the Workflow Patterns.

An evaluation of the Bizagi package. According to different sources, BizAgi is one of the biggest Business Process Modeling vendors in America. Which was established in 1989 and employing about130 people, the company focuses on the needs of the banking industry. The company has offices in different parts of the world such as UK and supporting banks and insurance customers. BizAgi has three areas which makes more exceptional from other BPM the capability which it gives when sharing data space, the case of handling functionality that this enables and the solution work process designed to support the common processes in Retail. First, despite than considering process relevant data as something outside of the process domain, that is requiring integration after modeling the flow of the process, with BizAgi it is at the core of how process based applications are developed and deployed. Many of the BPM systems have delegated the responsibility for management of the data to the third party applications (For instance parts Of Business applications based on an RDBMS) and do not inherently Understand the relationships between the process and the business objects (entities of the particular data) . In BizAgi, after being initially modeled the information domain, it is then re-usable and referencible inother processes. Many of the other Busines Process Model products require the re-implementation of the data model for each process, which is then lead toy change and adapte to the needs of that specific process. For a period of time, this data model becomes fractured and fragmented. In the case of BizAgi, the extension of an initial data model process can still occur, but the core data set is delivered as services that prevent processes from the information, enabling more effective reuse. Therefore while the first application may take a similar amount of time to develop and deploy, as it would with a competitive approach, it is this aspect of BizAgi that should be of interest to its users regardless of their niche. It is in the development of subsequent process applications where complexity (and with it development time) is reduced. Moreover, complexity is reduced further when

developing and modifying large and complex processes as the product automatically generates sophisticated user interfaces based on the needs of the process. This approach helps the business analysts with an environment where they will be concentrating on process design and improvement this would be without needing any king of programming skills. This sophistication of the shared data model provides another important benefit. It directly capable to support the delivery of a Case Handling environment, with multiple processes bound to the case as needed. Other approaches of Case Handling normally require the great care over the construction of the process variables to make sure that they can inter-operate with each other. The other thong is Bizagi processes already sher a mutual data model, the result of this, if you change model, let say when adding a new variable or customer attribute and it does not break the existing set of it. Conclusions As we have just examining the readability, comparison and an evaluations of both , through diagrams below and explanations, of business models written in BPMN and UML. We used some people are freshmen from the computer science and not familia with the language, we first expected that the BPMN models were easier to understand than UML, this assumption was derived from the BPMN primary goal and its distinct model elements not present in UML. Our study do not offer an evidence that exist differences in modelling using BPMN and UMLactivity diagrams from the point of view of the end users readability and we hope that these results will provide more of the information to an organization in deciding to adopt or not a new notation for the business modelling. In our study we have analysed only work flow patterns, this suggests that using this pattern the level of difficult for understanding the business process, in all the languages, is the same. This restriction is an important scope for future work. It is important to determine whether there are differences in the results using other workflow patterns. It is also important to determine if there are differences in other modeling activities like model writing. By our recommendation we would recommend the use of business process modelling as it give more flexibility and yet easy to be interpreted by customers that makes the growth of any enterprise to benefit from it. .
Below is our own examples created to evaluate activity diagrams In our example will find; ONLINE MERCHANT SYSTEM GARAGE SYSTEM WAREHOUSE SYSTEM.

Garage system UML process Model activity diagram.

Online Merchant system UML process Model activity diagram

Warehouse system UML process Model activity diagram

Garage system BPMN process Model activity diagram

Warehouse system BPMN process Model activity diagram

Online Merchant system BPMN process Model activity diagram

References

Eriksson & Penker, 2000 Eriksson, H., & Penker, M. 2000. Business Modeling with UML: business patterns at work. John Wiley & Sons. List & Korherr, 2006 List, Beate, & Korherr, Birgit. 2006. An evaluation of conceptual business process modelling languages. OMG, 2005 OMG. 2005. Unified Modeling Language Specification, version 2.0. Object Management Group (OMG). OMG, 2006 OMG. 2006. Business Process Modeling Notation Specification. Object Modeling Group. Scheer, 1999 Scheer, A. W. 1999. ARIS Business Process Modeling. 2nd edition edn. Springer Verlag. Mayer & Perakath, 1995 Mayer, R., Menzel C. Painter M. Witte P. Blinn T., & Perakath, B. 1995. Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report. Tech. rept. Knowledge Based Systems Inc. (KBSI). Russell et al., 2006b Russell, Nick, van der Aalst, Wil M. P., ter Hofstede, Arthur H. M.,

& Wohed, Petia. 2006b. On the suitability of UML 2.0 activity diagrams for business process modelling White, 2004 White, Stephen A. 2004. Process Modeling Notations and Workflow Patterns. Russell et al., 2006a Russell, N., ter Hofsted, A.H.M., van der Aalst, W.M.P., & Mulyar, N. 2006a. Workflow Control-Flow Patterns: A Revised View.