Business Process Model and Notation

About: Business Process Model and Notation is a research topic. Over the lifetime, 9038 publications have been published within this topic receiving 190712 citations. The topic is also known as: Business Process Modeling Notation & BPMN.

Discovering patterns of executions in business processes

Abstract: A computer-implemented method for analyzing business processes described in a business process execution language includes mapping a workflow abstract model graph from each of a plurality of business process descriptions corresponding to the business processes, identifying message exchange patterns between the business processes, and merging the workflow abstract model graphs into a common graph without connections between nodes associated with the plurality of business processes descriptions. The computer-implemented method further includes adding arcs between nodes of the different business processes descriptions within the common graph according to a merging rule and the message exchange patterns, and mining the common graph for a frequency of path execution, wherein a path is a set of nodes connected by the arcs.

Agent-based conceptual model representation using BPMN

Abstract: In a simulation project, a good conceptual model representation is critical for communicating conceptual models between stakeholders. A conceptual model describes the problem domain and model specifications. The description of the problem domain includes the objectives, inputs, outputs, content, assumptions and simplifications made in the model. The model specifications are used to specify the model's behavior. This article focuses on the representation of the model content (structure, boundary and level of detail) component of an agent-based simulation (ABS) model. For this, we propose the use of Business Process Model and Notation (BPMN) from the Object Management Group. A Web-based visual modeling tool has been developed using JavaScript to demonstrate how BPMN can be used to represent an ABS conceptual model and how the tool translates the conceptual model into code ready for execution using Repast HPC.

Security Analysis of Electronic Business Processes

Abstract: This article introduces POSeM, a method that uses business process descriptions to derive appropriate security safeguards. This is achieved by assigning security levels to the components of a business process such as actors, artefacts, and activities with a specially developed description language. These levels are checked for consistency, and security measures are derived using a configurable rule base that maps security objectives to safeguards. POSeM in practice is illustrated by an application to electronic business, i.e., the publication process of information for a company's web-site. Both the advantages of POSeM and its possible refinements are discussed.

Choosing Approach to Business Process Modeling - Practical Perspective

Abstract: One of the essential parts of a business process modeling project is choosing an approach to modeling and/or modeling notation/tool. The selection of a "right for the task" approach can substantially increase chances for success. To ensure the "right" choice, the following three sets of factors should be considered: (a) properties of modeling objects, i.e. business processes, (b) characteristics of the modeling environment, (c) intended use of the model. The paper is devoted to the analysis of these factors. It presents a simplified classification of the approaches to business process modeling. It lists the most essential properties of various business processes, it classifies modeling environments, and it discusses some practical tasks where the business process model can be used. Based on the analysis, practical recommendations on what approach to choose are given.

Relating Business Goals to Architecturally Significant Requirements for Software Systems

Abstract: : The primary purpose of the architecture for a software-reliant system is to satisfy the driving behavioral and quality attribute requirements. Quality attribute requirements tend to be poorly captured and poorly represented in requirements specifications, which focus on functionality. It is often up to the architect's own initiative to capture the actual quality attribute requirements for a system under development. Quality attributes come about because of the business goals behind the system being developed. Business goals drive the conception, creation, and evolution of software-reliant systems. This report examines business goals from the point of view of the software architect. It presents a wide survey of business goal categories from the business literature and uses that survey to produce a classification of business goals. It introduces the concept of goal-subject (the person or entity who owns the business goal) and goal-object (the person or entity that the goal is intended to benefit). Those concepts are essential to the structure of a business goal scenario -- a systematic way to elicit and express business goals. Using the concept of a business goal scenario drives the Pedigreed Attribute eLicitation Method (PALM), developed by the authors for eliciting architecturally significant business goals. The report illustrates how to use architecturally significant business goals to produce a set of derived quality attribute requirements that can then be vetted and elaborated with the appropriate goal-subject(s) and goal-object(s). This approach has been vetted in two workshops and the method piloted in an industrial setting.