Keywords

1 Introduction

1.1 Research Context

Business (often refereed to as enterprise) modeling provides guidance for the analyst on how to understand and represent the organizational setting through all of its processes. As-is process understanding is required for further process re-engineering or determining possible software systems support. In order to furnish adequate models to support such an activity, we need to model different levels of abstraction. Traditionally, a company structures around three (complementary) abstraction (or decision) levels – the strategic, tactical and operational level – each one requiring representation models. Furthermore, guidance for a follow-up between all hierarchy levels is required; i.e. knowledge must – at least partially – be refined and traceable.

Within the the Rational Unified Process (RUP) [10, 12, 25], the RUP/UML Business Use-Case Model Footnote 1 (BUCM) offers a syntax and semantic to represent the situation as-is at tactical and (at least partiallyFootnote 2) strategic level. The BUCM is, indeed, an extension of the Unified Modeling Language (UML) [17] Use-Case Model supported by the RUP and many Computer Aided Software Engineering (CASE) tools. Then, at the operational level, the representation is ensured by the UML activity model as defined in the OMG specification (see [17]). These are, nevertheless, primarily designed to document the to-be system behavior through the interaction with users. RUP defines no alignment (anchoring of elements) between the tactical and operational levels.

1.2 Towards the Combined Use of the RUP/UML Business Use Case Model and the BPMN Business Process Model

The RUP/UML BUCM and the Business Process Modeling Notation (BPMN) [1, 16, 26] Business Process Model (BPM)Footnote 3 have in common that they are targeted to pure business process modeling so that they dispose of a richer set of elements associated with precise semantics for this purpose. Even if they come from different semantic domains, some elements are semantically close enough and they can be used for anchoring (and traceability) among representation levels. That is why, previous research (see [29]) studies the possible anchoring between the RUP/UML BUCM and the BPMN BPM.

The conjunct use of these two frameworks is supported by CASE-tools like Rational Software Architect [23] or Visual Paradigm [18].

1.3 Research Context and Objective

As evoked, [29] evaluates the possible anchoring between the RUP/UML BUCM and BPMN BPM, but focuses exclusively on tactical and operational levels representation. It does not detail the strategic level and is thus an incomplete solution for full business modeling knowledge levels coverage.

The research developed in this paper further justifies the choice of the integration of the two frameworks and furnishes a meta-model for the full integration of the 2 frameworks and their use for knowledge representation and traceability among the three knowledge level representations. This unified-model has been used within the context of the Design of a Business Information System (DBIS) course within the Master in Business Information Systems (faculty of economics and business) at KU Leuven (campus Brussels). Further justification of the choices for framework selection can be found in Sect. 2. We specifically wanted to adopt BPMN BPM within the as-is business process modeling of a case study given to students. Within the context of the course, we (the teachers) have initially decided to integrate the use of the BPMN BPM for process operational level representation instead of the UML activity model because:

  • The BPMN BPM offers a set of (relevant) stereotypes with associated semantics to represent business processes in an operational manner because these were primarily engineered for enterprise modeling. The activity model does not offer these; this misalignment comes from the fact that they have been engineered to model user behavior with respect to a to-be software system;

  • The BPMN BPM is an increasingly important industry standard for enterprise modeling (see [14]);

  • The BPMN BPM offers the possibility to easily execute modeled workflows with a language as the Business Process Execution Language (BPEL, see [5, 19,20,21]);

  • Further extensions of the BPMN BPM include the definition of Key Performance Indicators (e.g. [7]) that could be applied to the BPMN BPM in our approach to evaluate their support to tactical and strategic aspect(s). This is left for future work.

Finally, poor (we could even say no) documentation and support is offered for the use of strategic modeling within the RUP/UML BUCM. That is why we distinguish here the strategic modeling level as a separate diagram to be built in parallel with the classical (business) use case model and allowing to trace the impact of processes (i.e. business use-cases) on the long term strategic goals and objectives. This is discussed in Sect. 5.

1.4 Added Value of Defining Anchoring Points Between the RUP/UML Business Use Case Model and the BPMN Business Process Model

The set of elements defined by the BPMN BPM allows better anchoring between the operational and tactical levels than the classical UML activity model. A preliminary question is, however, the utility of defining such anchoring points to ensure traceability between the different abstraction levels. We highlight the following benefits:

  • Ensure consistency during the refinement process. Providing anchoring points of elements from the models at the different abstraction levels helps to ensure that the vision of the reality built and shown in the different models (thus at different knowledge levels) is aligned rather than divergent. In other words, it allows building complementary models envisioning reality with the same perspective rather than building concurrent models envisioning reality with various perspectives;

  • Giving guidelines to modelers. By defining a set of anchoring points, modelers dispose of a clear set of guidelines for building and structuring their models; this is very useful for novice modelers (see Sect. 1.5);

  • Simplify the structuring in the refinement process. A set of elements present at the tactical level need to be present at the operational level, these can immediately be included in the operational view simplifying the structuring of diagrams;

  • Help communicating with stakeholders. The correct use of the anchoring guidelines allows to explain and justify modeling choices when communicating the produced models to stakeholders.

As said, the definition of these anchoring points has been done in [29] and are summarized in Sect. 4.

1.5 Added Value of the Integrated Framework and Contributions

As said, the integrated framework presented in this paper has been developed and applied in the context of an applied software engineering course at master level. When the course was initially defined and given, the BPMN BPM was integrated in the Business Modeling discipline of the RUP for operational workflow representation but without specific anchoring points with the RUP/UML BUCM. During the two first academic years, the teachers only gave the indication to use the BPMN BPM instead of the UML activity model in order to practice skills with the former framework (it was judged relevant for the reasons evoked previously). The course format stipulates that students receive real-life process descriptions (submitted to a major consultancy company, partner in the students’ solutions evaluation) and have to produce an initial as-is representation of the business processes. In practice, when modeling the case, students made a lot of round-trip between the abstraction levels (thus the RUP/UML BUC diagram and the BPMN process diagrams) while understanding and modeling the processes. This resulted often in a poor linkage between the tactical and operational diagrams. When questioned about it, students could hardly relate the different modeling levels and justify their choices. In the next (and last) two academic years, students received theoretical information about the anchoring points and could use these as modeling guidelines leading to more consistent models and the ability to justify some modeling choices. A formal evaluation of this is left for future work.

The primary contribution of this paper is the meta-model furnishing an integrated view for the conjunct use of the RUP/UML BUCM and the BPMN BPM; this one is intended to be used as guideline for the building diagrams documenting the organization and its processes on three layers (see Sect. 5).

The goal is not (necessarily) to push the adoption of “our integrated framework” into the industry but to teach business process modeling as a prerequisite in software development using industry adopted practices. This paper highlights possible anchoring between the frameworks to force the modeler to consider traceability when depicting the three knowledge (or decision) levels of an organization increasing the level of consistency between levels.

1.6 Paper Structure

The paper is structured as follows. Section 2 justifies the choice of the software engineering methodology guiding developments and its constituting artifacts. Section 3 overviews related work. Section 4 explains the theoretical background through the presentation of the mapping of elements from the RUP/UML BUCM and the BPMN BPM. The Section summarizes the work realized in [29] used as a basis for the present research. Section 5 studies the use of an integrated model on the basis of the alignment study performed and shows its applicability on an illustrative example. Finally, Sect. 7 concludes the paper.

2 Selecting a Methodology and Artifacts

The main issue when starting up the course in 2012 was to find a methodology being an adequate compromise between the best suiting method for a structured learning of software engineering and industry adopted practices. Indeed, one of the characteristics of the institution is the so called business-orientation and, since the students are in their Master year, they are very likely to be on the job market soon so that using industry adopted practices is of course favored. The first possible option to use methodologies and artifacts mainly used in the academic world like for example the i* modeling framework [30] or KAOS [27] was thus abandoned. Despite the real interest of these for their broad representation capabilities and their formal approach, they are far from being industry-adopted which partially conflicts with the objectives expressed earlier.

In order to conciliate with the objectives, we did a small informal survey of the frameworks used by the main consulting companies that are also teaching partners of the institution. This lead to the conclusion that each of them used their custom development method mostly documented internally within the company or group. A few common patterns could nevertheless be distinguished. They all:

  • devote significant effort to representing the as-is situation before depicting the situation to-be;

  • represent operational workflows using the BPMN BPM or very similar formalisms.

Pure agile methods are too informal and operational in their requirements definition so that we did not want to push them neither. The Rational Unified Process (RUP) nevertheless made a perfect candidate to be adopted as a guidance development methodology for the purpose of our course. Indeed, the business modeling discipline devotes significant effort to the representation as-is. This allows a structured approach of the development of software systems for heavy processes organizations and has already been identified in [2] as a strength of the framework for educational purpose. Indeed, from a strong identification of the as-is situation, the added value of the to-be situation can be showed/demonstrated.

We thus decided to select the RUP as a methodology but to study the possible integration of the BPMN BPM instead of the UML activity model within the business modeling discipline.

3 Related Work and Positioning

[24] claims that using of the UML use-case model associated with workflows in the context of business process analysis is useful and needs to be further studied. It thus advocates for the interest of our research.

[6] proposes yPBL, a learning methodology applied to Software Engineering (SE). The methodology is based on the well-known PBL method and adapted to SE unified processes. It specifies the relationship between the roles and phases considered in PBL methods and the roles, iterations and phases considered in the Two Tracks Unified Process (2TUP). The yPBL method concentrates on the realization of three tracks (i.e. functional, technical and development). The functional track considers a tactical level, the used models are the UML Use Cases and Activity ones.

As already evoked, [2] points to the use of the RUP for educational purpose notably because of the presence of the Business Modeling discipline. Within this discipline the RUP/UML business use-case model is defined and by including the BPMN BPM instead of the UML activity model in the RUP process, more formality and traceability is required which could have a positive impact on their approach of complex software problems. This approach is followed by this paper’s authors in the evoked course.

Artifacts for a tactical representation are present in the global BPMN framework and artifacts for an operational one are present in the UML, indeed:

  • Process Maps (PM) are included in BPMN; PM are made of coarse-grained elements with limited expressiveness. PM are only constituted by a set of elements representing sets of business processes and the triggering actors represented as lanes. PM are comparable to a classical use-case model but the RUP/UML BUCM offers richer representation possibilities;

  • The UML Activity Model define a set of elements for workflow modeling, but, as discussed earlier, the set of available elements is much poorer for pure business (enterprise) modeling than the ones of BPMN’s BPM because they are mostly oriented on representing software system behavior with user interaction.

Traceability studies and referrals between use-cases and business processes have been studied in both top-down and bottom-up perspectives.

[3] proposes an approach to obtain a use-case model from a business process model. It builds a complete use case model – including the identification of actors, uses cases and the corresponding descriptions – which are created from a set of predefined natural language sentences mapped from the BPMN BPM elements. The approach is divided in two parts. The first one presents a set of rules to obtain a use-case diagram from a BPMN process diagram. Then, the rules are used to derive the description of the uses cases previously identified. When sub-processes are involved, the approach demands that they are fully expanded which induces losing some structure information. [22] details how to make use of the Visual Paradigm Model Transitor function to build a use case model from a BPMN process diagram. It nevertheless remains a tool-based approach with no formal rules.

In opposition to the previous approaches, [9] suggests to use the BPMN BPM instead of the UML activity model in the RUP process. Their study showed that the perceived complexity of a BPMN process diagram is lower than the one of an activity diagram. The only guideline given in the paper is the use of one BPMN process diagram to depict one particular use-case; no further traceability rules are given. Similarly, [13] studies traceability between use-case elements and the BPMN BPM. They distinguish the same integration approach as we do plus distinguish an upper level to depict the sequence of the use-cases themselves. Such an encapsulation is notably supported by Visual Paradigm (see for example [28]) and was already supported in the same way in Rational Rose but with UML activity diagrams only and we inherently encompass the same encapsulation in our approach (see Sect. 4). We suggest to have a finer level of traceability meaning to trace elements constituting the RUP/UML BUCM with elements from the BPMN BPM.

Finally, [4] proposes a mapping from the BPMN BPM to a formal language, namely Petri nets, for which efficient analysis techniques are available. This work is complementary and could be integrated into the RUP for the forward engineering of business process models. As evoked in the introduction, the BPMN BPM has also mapping approaches to other execution languages like for example BPEL.

4 Theoretical Background

[29] has studied the alignment between the elements from the RUP/UML BUCM and BPMN’s BPM. To such an extend, the RUP/UML BUCM’s elements defined in the business modeling discipline of the RUP knowledge base (see [11, 12, 15]) were taken as input elements to be mapped. More precisely, three categories of elements were distinguished: Inheriting from Use Case (IUC), Inheriting from the Actor (IA) and Links (UMLLink). The icons of the RUP/UML BUCM are represented in Fig. 1. Similarly, on the basis of the documentation found in [16], Wautelet et al. [29] has built four categories of elements within the BPMN BPM ones: Events (Evt), Activity (Act), Gateway (Gwy) and Connections (Cnt). In this section, we relate the transformations in a top-down manner meaning that we start from tactical elements (from the RUP/UML BUC Model) and see how they are mapped to the operational elements (from the BPMN BPM).

Fig. 1.
figure 1

Icons of the RUP/UML business use-case model.

Full size image

We are, of course, aware of the fact that we are facing two different semantic domains and that a perfect alignment is illusive. Nevertheless, since the two frameworks are devoted to business modeling their semantic coverage is rather close and (as will be seen in the next section) the mappings that have been made are (rather) consistent.

Fig. 2.
figure 2

Tracing business use cases and BPMN process diagrams (from [29]).

Full size image

4.1 Traceability of Inheriting from Use Case Elements

The elements from the IUC category (which could be seen as stereotypes of the classical UML use-case element) are coarse grained (so very abstract) ones. It means that each elements of this category encapsulate an entire (business) process so are not suited for traceability at individual level with elements grouped in the categories of the BPMN BPM. [29] indicates to map a Business Use Case Realization (BUC Realization) element with one BPMN Process Model. Following the RUP knowledge base, a Business Use Case (instance) is a sequence of actions that a business performs that yields an observable result of value to a particular business actor. The BUC Realization represents an entire business process and [29] thus suggests to encapsulate the details of its realization within a BPMN process diagram; this is represented in Fig. 2. This two-level abstraction view is fully supported by Visual Paradigm (see for example [28]).

4.2 Traceability of Inheriting from Actor Elements

Contrarily to the elements of the IUC category, the ones of the IA (which could be seen as stereotypes of the classical UML Actor element) can be traced (with BPMN BPM elements) at an individual level. Table 1 summarizes the mapping of elements between the RUP/UML BUCM IA category elements and the BPMN BPM ones performed by [29]. The interested reader can refer to the former sources for full justifications.

Table 1. Mapping of inheriting from actor (IA) elements
Full size table

4.3 Traceability of Link Elements

The impact of the elements of the Link category present in the RUP/UML BUCM can be traced as a set of constraints within the BPMN BPM elements. The rules established by [29] are the following:

  • Association directed from IA to IUC element: the IA category element triggers the action so that the Start Event from the BPMN process diagram depicting the IUC category element should be placed in the swimlane corresponding to the IA category element;

  • Association directed from IUC to IA element: the IA category element is involved in the realization of the process but not triggering the action so that this IA category elements must be found as a swimlane or pool in the BPMN process diagram, but does not host the start event (it can possibly host an intermediate or an end event);

  • Include: A IUC category element is included in another IUC category one so that the IUC element representing the “main” process includes as a sub-process in its BPMN process diagram the second one; the latter must be executed in any path of achievement of the main process;

  • Extend: A IUC category element is thus extended by another IUC category one so that the IUC element representing the “main” process includes as a sub-process in its BPMN process diagram the second one; the latter may be executed in the path of achievement of the main process but not necessarily.

  • Generalization: A generalization can take place both between elements of IA category or the IUC one in the RUP/UML BUCM.

    • When there is a generalization between 2 elements of the IA category, it cannot be traced at the level of the BPMN process diagram;

    • When there is a generalization between two elements of the IUC category and the parent is abstract, only a BPMN process diagram is build for the realization of the child IUC category element. If it is not abstract, a BPMN process diagram is also associated with the parent IUC category element.

5 Three Layered Approach for Business Modeling

This section integrates the findings of [29] and suggests a way to integrate the strategic, tactical and operational levels in a unified framework based on the RUP/UML BUCM and the BPMN BPM. The findings of the mapping/alignment study are finally presented and summarized through a meta-model in the form of a class diagram in Fig. 3 and illustrated on a case study. The case study takes place in the chocolate industry.

My Chocolate Factory Footnote 4 (MCF) is a company producing and selling chocolates that has commercial presence in 3 continents and manufacturing activity in 2 of them. The focus of growth of MCF is the Asian region, and its main competitive advantage is the vertical integration with providers and customers, developing quality through all the production stages. In order to support this, MCF requires a system able to integrate the most important activities, in a non-redundant, stable and user-friendly way. The company of Thailand is the scope and the first phase of the new system implementation because it covers both manufacturing and sales process, and is the center of operations in the actual market of Asia. Part of this case is presented in this in Fig. 4; The goal of the Section is to give a perspective on the use of the integrated framework and not to illustrate each cases of tactical/operational traceability. It depicts a reinterpretation of the strategic aspects of the RUP/UML BUCM – because that perspective is not formally defined and illustrated in literatureFootnote 5 – as well as the integration of the strategic, tactical and operational levels on one case.

5.1 Strategic Modeling: The Business Goal Model

The Strategic Level is concerned with decisions including the general direction i.e. long term goals, philosophies and values. In a SE perspective, we would be willing to represent the goals of the organization as well as the processes it is involved in but in a coarse-grained, non-sequential and non-prioritized manner in order to trace support.

The RUP knowledge base defines a business goal as a requirement that the business must satisfy. It argues that business goals describe the desired value of a particular measure at some future point in time and can therefore be used to plan and manage the activities of the business. It also distinguishes business objectives as high-level business goals and emphasizes that because business objectives are usually abstract, they are difficult to measure and are therefore translated into more measurable lower-level business goals. Both elements are represented with the same icon.

Business Goals in the large sense (including business objectives) are very interesting in the context of modeling a software system since they allow to include a representation of the business strategy. Indeed, [11] highlights that the purpose of business goals is to translate the business strategy into measurable steps with which the business operations can be steered in the right direction, and, if necessary, improved. In that context, both concepts of business goals and objectives are interesting, they are mainly distinguishable by the fact that the first one can be directly associated with a metric while the second needs to be refined in more business goals for measurement. Business goals can then be supported by BUC themselves realized through BUC Realizations allowing to draw a full and clear hierarchy. This will be further discussed into Sect. 5.1.

The RUP knowledge base defines a business goal as a requirement that the business must satisfy. It argues that business goals describe the desired value of a particular measure at some future point in time and can therefore be used to plan and manage the activities of the business. It also distinguishes business objectives as high-level business goals and emphasizes that because business objectives are usually abstract, they are difficult to measure and are therefore translated into more measurable lower-level business goals. Both elements are represented with the same icon.

Business goals and objectives are very interesting for enterprise modeling since they allow representing the business strategy. Indeed, [11] highlights that the purpose of business goals is to translate the business strategy into measurable steps with which the business operations can be steered in the right direction, and, if necessary, improved. These two elements are mainly distinguishable by the fact that the first one can be directly associated with a metric while the second needs to be refined in more business goals for measurement. Business goals can then be supported by BUC themselves realized through BUC Realizations allowing to draw a full and clear hierarchy.

Few sources and examples are available to depict how they can/should be used in a project. In [11], the business objectives and goals are decomposed in a tree structure and, within the RUP/UML BUCM, business use cases trace their support of lowest level goals only. To clearly highlight the strategic level, we point to the use of an independent model (that we simply call the business goal model) at strategic level only relating the business objectives, goals and their refinement as well as the business use-cases supporting these goalsFootnote 6; no actor should be present in it (actors will be later documented at tactical level). RUP/UML business goals are related using a Dependency relationship (arrow) originating on the highest level goal and pointing to the lower level one. Similarly, when a RUP/UML business use-cases supports a business goal it is linked using a Dependency relationship stereotyped supports from the the former to the later.

Fig. 3.
figure 3

Unified business modeling framework: Meta model.

Full size image

The upper left part of Fig. 3 (the transparent classes) concerns the RUP/UML Business Goal Model. The latter is composed of the Business_Objective, the Business_Goal and the Business_Use_Case classes. Instances of the Business_Goal class (so Business Goal elements) can be linked through a Refine_Dependency_Link. Similarly, different instances of the Business_Goal class (thus different Business Goal elements) can be linked through a Refine_Dependency_Link. Instances of the Business_Use_Case class (so Business Use Case elements) support the Business_Goal class by offering support so through a Supports_Dependency_Link.

The strategic layer in Fig. 4 illustrates the Goal Model. The business objective Sustainable Growth is refined in another business objective (Increase Customer Loyalty) and more business goals. Also, business use-cases support the realization of certain goals, we can notably cite the goal Manage Procurement that, within its realization, can favor the performance of the goal Acquire Raw Material Locally.

5.2 Tactical Modeling: The Business Use-Case Model

The upper middle and left part of Fig. 3 (the mid-dark classes) concerns the Business_Use_Case_Model. The latter is composed of the Business_Use_Case_Realization, the Business_Actor, Business_Worker, Business_Entity, Business_Event, the Include_Dependency_Link and the Extend_Dependency_Link classes. Business_Use_Case_Realization elements are instantiated and correspond to the Business_Use_Case elements depicted in the goal model in a 1 to 1 fashion. These Business_Use_Case_Realization elements are triggered by Business_Worker or Business_Actor elements.

The tactical layer of Fig. 4 is illustrated by a business use-case diagram. Each BUC Realization in the diagram (i) corresponds to a BUC distinguished at strategic level that prescribes what should be done to obtain value (and thus linked with the Business Goals and Objectives) and (ii) encapsulates a description in the form of a BPMN process diagram of the process realization scenarios. Traceability between the strategic and the tactical layers is thus ensured through the mapping of BUC and BUC realizations.

5.3 Operational Modeling: The BPMN Business Process Model

The lower part of Fig. 3 (the darkest classes) concerns the BPMN_Business_Process_Model. The latter is composed of the Lane, Pool, Data_Object, Start_Event, Intermediate_Event and Subprocess classes (only elements that are traceable from the (tactical level) business use-case model are represented). As evoked previously, a Business_Use_Case_Realization element should lead to one BPMN process diagram. The latter inherently instantiates a main Pool element corresponding to the main organization modeled. Within this Pool, a Business_Worker element instantiates a Lane element. Similarly, a Business_Actor element instantiates another (thus separate) Pool element.

The operational layer in Fig. 4 illustrates a BPMN process diagram. The Make-to-Stock BUC Realization is here depicted as a set of activities. We can highlight that the Salesman which is a Business_Worker can be traced in the form of Lane in the My_Chocolate_Factory Pool. Also, the Customer which is a Business_Actor can be traced in the form of a separate Pool. The Sales_Order which is a Business_Entity can be traced in the form of a Data_Object. Traceability between the tactical and the operational layers is thus ensured by (i) the BPMN process diagram describing realization scenarios for BUC realizations and (ii) elements constituting the BUC Model described in the BPMN process diagram.

Fig. 4.
figure 4

Unified business modeling framework applied on the case study.

Full size image

5.4 Integration in the RUP Process

The integration of the framework into the Business Modeling discipline must be done at artifact level. Indeed, following [10], An artifact is a piece of information that is produced, modified, or used by a process. Artifacts are the tangible products of the project, the things the project produces or uses while working towards the final product. Artifacts are used as input by workers to perform an activity, and are the result or output of such activities. The BUCM is already part of the process’ artifacts; the Goal Model can be integrated into strategic activities as a new artifact allowing Goal reasoning. Similarly, BPMN process diagrams could just substitute UML activity diagrams since they have the same representation possibilities but offer richer semantics.

6 Framework Acceptance and Results

The framework is currently being further validated through the use of students’ produced models. The validation is made longitudinally and cross-sectionally. We are comparing the work produced by cohorts of students from different generations. Concretely a same case has been modeled by students that have only been taught the basic artifacts from the RUP and BPMN and by students that have received a specific training on the structure and traceability rules. All of the students reports are given a score in function of the (i) the quality of the application of the structure and traceability (including the cohort not familiar with the framework of this paper), and (ii) on the general quality and completeness of the models produced. We then compare the results of the 2 cohorts (without and with knowledge of the framework). Across the cohorts, traceability scores are also correlated to the general scores. The full validation of the framework will be part of a future communication in the form of a scientific article.

7 Conclusion

The conjunct use of the RUP/UML BUC Model and the BPMN BPM leads to an integrated framework that allows to model both the strategic, tactical and operational layers of a business modeling problem. The framework has been used in the context of structured learning of software engineering in a master course on information management. With respect to the traditional RUP approach, the pedagogical approach is enhanced because of the strength of the framework to enforce traceability at all levels thanks to the richer semantics proposed by BPMN’s BPM compared to the classical UML activity model. Also, it allows to use the BPMN BPM that is widely adopted in the industry.

The coupling of elements could be made stronger if backed by an empirical evaluation of the choices that would be made by practitioners. This particular point will also be the subject of a study in the coming months. Future work includes the evaluation of the benefits of framework use in various contexts. Indeed, as evoked, the primary willingness of its use is pure business modeling so not necessary leading to software development. It can indeed be used to audit business processes in order to point out weaknesses and optimization flows, for modeling the as-is situation in off-the shelf software development (like for integrated ERP systems), etc.