Separation of concerns has long been an important strategy to deal with complexity when developing a system. Some concerns (like security) are scattered through the whole system, and different modules are tangled to such concerns. These concerns are known as cross-cutting concerns.When the system in question is a business process, cross-cutting concerns are aimed at being encapsulated by Aspect-Oriented Business Process Modeling. However, the state-of-the-art techniques in this field lack efficient mechanisms that (1) support composition of cross-cutting concerns that can be defined in parallel to (a part of) a process model and (2) enable specifying both mandatory and optional cross-cutting concerns. To address these limitations, this paper proposes a new Aspect-Oriented Business Process Modeling approach. The approach is hybrid since it is based on declarative rules to relate imperative cross-cutting concerns and imperative business process models. The approach is explained, formally grounded with precise semantics, and used accordingly to implement the artifacts that support modeling and enactment of business processes in the proposed fashion as a proof of concept. In addition, the approach is evaluated on the basis of the Technology Acceptance Model during a workshop session. The result shows that participants perceived the approach usable and easy to use. KEYWORDS aspect orientation, business process modeling, cross-cutting concerns, declarative rules, hybrid models
INTRODUCTIONSeparation of concerns is an important strategy for people to deal with complexity. This strategy has been widely used and adopted in developing systems where designers can divide the specifications of systems into smaller individual modules. These modules can be managed, understood, and changed separately but integrated into a comprehensive, overall specification. The lack of a proper separation can lead to very intertwined complex systems, which are hard to be changed and managed.Business processes are examples of such systems, which can be defined through sets of constraints to fulfill specific goals. These constraints specify how activities in a business process can be managed, and they are categorized into 2 major groups. One group consists of procedural flow-based constraints that specify how a business process should be performed step by step. The other group consists of very flexible models suitable for specifying processes characterized by high variability, which can hardly be specified as a predetermined procedure. We call the models in the first group imperative models while those in the second group declarative models. 1 Imperative models specify the behavior of flow-oriented and rigid business processes. In these models, the behavior of a process is specified explicitly. Imperative models can be expressed using Business Process Model And Notation (BPMN), 2 Yet Another Workflow Language (YAWL), 3 Petri nets, etc. In contrast, declarative models allow all behavior to happen unless it is explicitly forbidden. Thus, they suit...