Keywords

1 Introduction

The essence of legacy system migration is to move an existing, operational system to a new environment, retaining the functionality of the legacy system while causing as little disruption to the existing operational and business environment as possible [1]. Legacy system migration is a very expensive procedure which carries a definite risk of failure. Consequently before any decision to migrate is taken, an intensive study should be undertaken to quantify the risk and benefits and fully justify the redevelopment of the legacy system involved [2, 3].

Reverse engineering techniques have become very important within the legacy system migration process, providing several benefits. Firstly, reverse engineering allows the retrieval of abstract representations to facilitate the comprehension of different legacy systems, such as relational databases [4] and aspect oriented systems [5]. Secondly, abstract representations obtained by reverse engineering from legacy systems can be refactored to improve their maintainability or add new functionalities to evolve legacy systems. To meet these demands, business process archaeology has emerged as a set of techniques and tools to recover business processes from source code [6]. One of the main benefits of business process archaeology is that it preserves business behaviour buried in legacy source code and it retrieves business processes, thereby providing more opportunities for refactoring due to the higher abstraction level.

During business process refactoring new security features can also be introduced to evolve the legacy business processes. Since the advantages of the early identification of security requirements are recognised by the consensus of the RE literature [7, 8], it is imperative that security concerns are taken into account during the early redesign stages of such systems. An advantage of eliciting security requirements in the early (re-)development stages is the lower possibility of security issues arising when the system is already in use, which would require redesigns and significant downtimes, thus proving costly for enterprises [9].

The security objectives of an enterprise are expressed via security requirements, which are used as input during the redesign of the business processes supported by such legacy systems. The development of “secure by design” business processes is considered highly beneficial as information security breaches can impact enterprises both financially and in terms of reputation and trust from the customer’s side. It can also be a legal obligation to regulate and ensure the security of sensitive information handled by business processes [10]. However, despite its apparent importance and the potential to greatly benefit modern business processes, security is usually considered as an afterthought during their development in practice [11] and receives little attention from business process management (BPM) approaches developed in research [12, 13].

In this work we present a novel approach for the modernisation of legacy systems from an information security point of view. It facilitates the elaboration of security requirements via Secure Tropos goal models, derived from legacy business processes which are automatically extracted from their legacy source code. Therefore, by integrating existing and novel components, the proposed approach facilitates a unique transformation of the lowest abstraction level of legacy systems (i.e., source code) to highly abstract enterprise models in a largely automated manner. As a result it offers to non-technical enterprise stakeholders a platform appropriate for capturing high-level organisational security objectives in the form of security requirements, which can then be integrated back to the business processes as security features.

The rest of the paper is structured as follows; Sect. 2 presents related work in the areas of process archaeology and goal-to-process model transformations. Section 3 introduces our approach and its four building blocks: (i) the MARBLETM framework for the derivation of a process models from legacy source code, (ii) the IBUPROFEN algorithms for the refactoring of the extracted process model, (iii) the Secure Tropos approach for security-oriented goal modelling and (iv) the transformation algorithms for the transition from process to goal models and vice versa. In Sect. 4 our approach is applied to a module extracted from a real software application, while final conclusions are provided in Sect. 5.

2 Related Work

2.1 Process Archaeology

Business process archaeology [6] studies the business processes in an organization by analysing the existing software artefacts. The objective is to discover the business forces that motivated the construction of the enterprise information systems. On the one hand, traditional archaeologists investigate several artefacts and situations, trying to understand what they are looking at, i.e., they must understand the cultural and civilizing forces that produced those artefacts. Similarly, a business process archaeologist analyses different legacy artefacts such as source code, databases and user interfaces and then tries to learn what the organization was thinking while also attempting to understand why the organization developed the information system in a particular way. The business process archaeology initiative is being progressively supported by new reverse engineering techniques and tools to retrieve and elicit the embedded business knowledge. One of these tools is MARBLETM [14, 15], a business process archaeology method to rebuild business processes embedded in legacy information systems.

2.2 Aligning Business Processes with Organisational Goals

The organisational context of the enterprise enacting a business process, provides valuable input for its successful (re-)design. Since graphical process modelling standards are not fully equipped to encapsulate such context, goal-oriented modelling languages are better suited for that purpose [16] since they can capture the intentions of stakeholders as system requirements [17]. Nevertheless, while goal models can provide a high-level direction and rationale in the form of goals, they lack the ability to adequately identify the specifics of their implementation at the process level. Thus goal-oriented requirements engineering (GORE) should be used more as a starting point, rather than a complete solution for the further development of process designs [18].

To that end, a number of approaches have been developed starting from goal models and eliciting business process designs. Mappings between organisational goals and process activities are introduced by such approaches in order to facilitate the transition between goal and process models. A variety of GORE frameworks have been utilised, such as KAOS in [19, 20], Tropos in [21, 22] and i* in [23–25]. Such generic model transformation approaches lack a clear security orientation so they are unable to capture the essence of security requirements, which, as opposed to functional requirements, act as restrictions on the means used for the achievement of goals.

To cover that need, certain security-oriented approaches have been developed. In [26], SecureBPEL is introduced as an extension of the BPEL execution standard enriched with constructs from the Secure Tropos goal-oriented framework, to enforce delegation and trust requirements in web services used to support the designed business process. In [27] the SecCo (Security via Commitments) framework is introduced for the elicitation of security requirements that need to be fulfilled by the organisation’s business processes, through the modelling and analysis of objectives, roles and social commitments between actors. Similarly in [28], transformation rules expressed in SecBPMN are used to introduce security requirements, identified using STS-ml, to existing BPMN process models.

Nevertheless, such attempts are unable to incorporate concepts and mechanisms to deal with the whole range of security requirements and also take into account elements of risk analysis (e.g., threats). As a result, in order to cover all aspects of risk and security a number of such approaches have to be used simultaneously, leading to a large overhead in time and specialised personnel and a high level of complexity. In addition, the simple annotation of existing process models with elements of security is not aligned with the notion of “security by design”, which requires the derivation of such process designs from high level, security- and risk-aware organisational models. Moreover such attempts cannot adequately capture and reflect the rationale behind security decisions at an appropriate level of abstraction as they usually just impose general restrictions on the interactions between participants of the process (i.e., at conversation diagram level) but not on their specific activities (i.e., workflow level).

3 Proposed Approach

3.1 MARBLETM Framework

MARBLETM is a technique and a tool that supports business process archaeology by retrieving business processes from legacy source code [6]. MARBLETM utilises an extensible, ADM-based framework for recovering business processes. To achieve that: (i) the information is collected into and is used from standard KDM (Knowledge Discovery Metamodel) [29] repositories and (ii) the information of KDM repositories is used to retrieve business process models [30].

Fig. 1.
figure 1

MARBLETM, a framework to support business process archaeology [6]

Full size image

MARBLETM focuses on the reverse engineering stage of the re-engineering process. It proposes four abstraction levels (with four different kinds of models) as well as three model transformations between them, in order to cover the whole path of the business process archaeology method between legacy information systems and business processes (see Fig. 1). The four generic abstraction levels proposed in MARBLETM are the following:

  • Level L0. As the lowest level of abstraction, L0 represents the legacy information system (LIS) in the real world as a collection of different software artefacts (e.g. source code, database, documentation).

  • Level L1. This level consists of several specific models, i.e., one model for each different software artefact involved in the archaeology process (e.g., source code, database, user interfaces). These models are considered to be PSM (Platform-Specific Models) since they depict the software artefacts according to their specific technology or platforms.

  • Level L2. It consists of a common PIM (Platform-Independent Model) which represents the integrated view of the set of PSM models at L1. The standard KDM metamodel is used for this purpose, since it makes it possible to model all the artefacts of the legacy system in an integrated and technological independent manner.

  • Level L3. As the highest level of abstraction, L3 represents a computational independent model of the system. It depicts the business processes retrieved from the knowledge concerning legacy information systems represented in the KDM repository at L2. Business process models at L3 are represented according to the BPMN (Business Process Model and Notation) metamodel [31].

MARBLETM provides a Java parser to obtain code models, which are transformed and integrated in a model repository according to the KDM standard. After that, KDMs are transformed to business process models by applying business pattern recognition. Finally, the tool allows the discovery, visualisation and editing of business process models. An in-depth elaboration of the framework’s functionality and capabilities is provided at [6, 14].

3.2 IBUPROFEN

Business process models derived via the reverse engineering approach followed by MARBLETM often require some refinement before they can be utilised for further transformations. For such purposes the IBUPROFEN (Improvement and BUsiness Processes Refactoring OF Embedded Noise) approach has been developed, which introduces a set of algorithms for the refactoring of business process models expressed in BPMN [32]. It introduces a set of ten refactoring algorithms which can be applied on business process models represented by graphs, expressed in BPMN. These ten refactoring algorithms are divided into three categories regarding their purpose, namely: maximization of relevant elements, fine-grained granularity reduction and completeness. An overview of the refactoring performed by each of these algorithms is provided in Fig. 2 and in [33].

Fig. 2.
figure 2

Process model refactoring algorithms introduced by IBUPROFEN [33]

Full size image

3.3 Secure Tropos

Secure Tropos [34] is a security-oriented extension of Tropos, a goal-oriented requirements engineering method. This extension includes the concept of security constraint which is defined as a restriction related to security issues, such as privacy, integrity, and availability [35]. Security constraints can influence the analysis and design of the information system under development by restricting some alternative design solutions, by conflicting with some of the requirements of the system, or by refining some of the system’s objectives. In addition, Secure Tropos defines secure dependencies which introduces security constraints that must be fulfilled for the dependency to be satisfied. A security mechanism represents potential solutions for the implementation of the security constraints, leading to the fulfilment of security objectives. The advantages of this approach, compared to other security-oriented software engineering approaches are: (i) its ability to perform social analysis during the early requirements stage, (ii) the simultaneous consideration of security with the other requirements of the system-to-be, (iii) the support for not only requirements stages but also design stages.

3.4 Model Transformations

A series of transformation rules need to be defined in order to facilitate the transition from business process models, expressed in BPMN and derived from legacy source code using the MARBLETM framework (Fig. 3 Phase 1), to Secure Tropos goal models. This process-to-goal transformation will create an additional, higher level of abstraction, represented by a goal model of the legacy system. At this level of abstraction it is easier for non-technical stakeholders to elaborate on the overall system security by defining certain easily comprehensible constraints. Such constraints can be captured by the Secure Tropos goal model and mapped back onto the process model, in order to be implemented during the redesign of the legacy systems.

Fig. 3.
figure 3

Extended framework to accommodate goal model reasoning

Full size image

Essentially, the proposed transformation aims to derive a goal model, on which security will be elaborated and expressed using Secure Tropos. A goal-to-process transformation can then be performed, beginning from the Secure Tropos goal model and deriving a secure business process model, used as input for the legacy system redevelopment via the MARBLETM framework. The overall process, containing an extra level of abstraction accommodating the security-oriented, goal model reasoning is illustrated in Fig. 3 and summed-up in Subsect. 3.5.

Transformation rules have been defined which map Secure Tropos and BPMN concepts to each other and provide instructions on how the transformation can take place. Such mappings are based on conceptual similarities between the paired concepts, identified after semantic analysis of the formal documentation and meta-models of the two modelling approaches [31, 34]. A process-to-goal transformation algorithm has been defined at Table 1, utilised in order to transform the refactored process model by IBUPROFEN (Fig. 3 Phase 2) to a Secure Tropos goal model (Fig. 3 Phase 3).

Table 1. Algorithm for Phase 3 of the transformation process
Full size table

By the application of the above transformation rules to a process model derived by the MARBLETM framework and refactored using the IBUPROFEN algorithms, a basic Secure Tropos goal model can be produced. This basic goal model is the main input upon which the security elaboration of the system will take place by stakeholders of the organisation. As a result of this security elaboration, security constraints, objectives and mechanisms are added to the Secure Tropos goal model to capture the security aspects that will be introduced to the legacy system during its redesign (Fig. 3 Phase 4).

The security-oriented concepts of Secure Tropos (i.e., security constraints, mechanisms and threats) cannot be directly mapped onto existing BPMN concepts. Therefore, some manual tasks need to be performed in order for the process model to reflect the security choices captured at the goal model level (Fig. 3 Phase 5). Table 2 presents an algorithm providing a precise set of instructions for performing such goal-to-process refinement tasks.

Table 2. Algorithm for Phase 5 of the transformation process
Full size table

3.5 Overview of Approach

As illustrated in Fig. 3, the proposed approach consists of the following phases:

  1. 1.

    Extraction of BPMN process models from the source code of the legacy system using the automated MARBLETM tool [15].

  2. 2.

    Refactoring of the extracted process model using the IBUPROFEN algorithms, automated via an Eclipse plugin [32].

  3. 3.

    Process-to-goal transformation using the algorithm of Table 1 to create an initial goal model from the refactored BPMN process model.

  4. 4.

    Security elaboration for deriving security requirements, threats and security mechanisms using the Secure Tropos approach via the SecTro tool [36].

  5. 5.

    Process model refinement using the algorithm of Table 2 for the addition of the security features elaborated at the Secure Tropos goal model.

The result of the application of above approach is a secure business process model, aligned with the high-level enterprise security objectives. This process model, which operationalises the security requirements captured at the goal model level, can be then used as input for the legacy system redevelopment effort, as proposed by the MARBLETM framework. Therefore the security features introduced at a high level from the organisation’s stakeholders will be included at the legacy system during its modernisation.

4 Illustrative Example

4.1 System Description

JBooksFootnote 1 is a Java-based personal finance application utilising a checkbox based interface that allows users to insert and visualize transactions. It is interfaced with a relational database, and involves a double-entry system for all transactions (i.e., every transaction involves a transfer from one account to another). A module of the JBooks application was selected for the purposes of this example. This module receives a string as input and if it is numeric it converts it to text in order to be further utilised by other modules of the application.

4.2 Method Application

The first phase of the method application is the extraction of a process model from the source code of the JBooks application. By using the MARBLETM tool we extracted a large amount of process models for the different modules of the JBooks application. For this example we selected a relatively simple process model representing the module that converts numerical strings to text.

After the initial process model is extracted via the MARBLETM tool it is refactored by applying the algorithms of IBUPROFEN. During refactoring some elements of the process model are replaced by equivalent ones or merged to reduce the complexity of the overall model. Since the refactoring process does not fulfill the commutative property, the order of the application of the algorithms is critical as it can define the quality of the outcome model [33]. The optimal execution order that maximises the understandability and modifiability of the process model has been experimentally identified as: first applying the granularity reduction set of algorithms, then the irrelevant elements reduction set of algorithms and finally the completeness algorithms [33]. The IBUPROFEN algorithms are implemented as a plugin of the EclipseTM environment on the process model extracted by the MARBLETM tool. In our example, after applying the refactoring algorithms, the process model illustrated in Fig. 4 is derived.

Fig. 4.
figure 4

Process model of JBooks module

Full size image

Next, the transformation of the derived process model to a Secure Tropos goal model need to be performed. By applying the algorithm in Table 1 to our example one actor is created to correspond to the lane of the process model (Step 1), each sub-process and task is transformed to a (sub-)goal (Step 2) and resources are created, corresponding to the data object of the process model (Step 3). In addition to the transformation steps defined by the algorithm, an extra root-level goal has been added to provide context to the derived Secure Tropos goal model, modelled using the SecTro tool [36], as illustrated in Fig. 5.

Fig. 5.
figure 5

Derived goal model of selected JBooks module

Full size image

As goal models in general, and Secure Tropos in our case, do not provide the means to capture temporal dimensions (i.e., the sequence of goal achievement), the resulting models cannot always capture all the information contained in process models. In our example, the application of Step 5 of the transformation algorithm cannot sufficiently capture in the goal model the fact that the activity “Get Object” is followed by either “Text handling resource” or “Number to Text resource”. This is due to the fact that Secure Tropos does not offer special notation for illustrating OR decompositions or the specific sequence of execution of goals. In order to resolve this issue a new goal had to be manually added (“Handle object”) which includes the two alternatives (i.e., “Text handling resource” or “Number to Text resource”) as sub-goals and is connected with an AND relationship with the “Get Object” sub-goal.

Fig. 6.
figure 6

Security-annotated goal model of JBooks module

Full size image
Fig. 7.
figure 7

Secure BPMN process model of JBooks module (Color figure online)

Full size image

During security elaboration process the system stakeholders can express their security requirements and define the basic mechanisms to implement them, using the goal model as a high level representation of the application. For simplicity purposes, our example includes one security constraint, concerning the validity of the input. It is related to the integrity of the input data and can be implemented by a security mechanism validating that it has not been altered before it reached the module. A threat has also been included in the goal model representing the malicious alteration of the module’s input by a third party. The complete, security-annotated goal model is presented in Fig. 6.

Finally, the security introduced at the goal model level has to be transferred back to the initial process model, by following the steps defined in Table 2. The finalised secure process model, illustrated at Fig. 7, now includes a secure task, denoted by a padlock symbol, representing the data validation security mechanism. The “Get Object” task is annotated with a red border to denote that it is security constraint while it is also an error event, annotated as an orange circle, is attached to represent the malicious data modification threat.

4.3 Lessons Learned

The addition of security in a module of the JBooks legacy system provided insights concerning the completeness and applicability of the proposed approach. Even though the example used was rather limited in size and complexity, we were able to successfully complete each step of our approach without any major complications. Some manual intervention was necessary after the refactoring of the process model in order to make the produced model more readable (e.g., reshaping and spacing elements and association links). Moreover the seamless transition between its different components added to the value of the approach, facilitated by the fact that the output for each phase can be used quite effortlessly as the input of the next. The availability of CASE tools (e.g., MARBLETM tool, IBUPROFEN plugin, SecTro tool) further contributed in the aspect of automation, as most phases, with the exception of the goal-to-process transformation, required minimal manual efforts. By expanding and interfacing the available support tools, this automation can be further strengthened in the future.

Regarding the transformation process, one addition to the proposed algorithm consisted of creating a root-level goal in the produced goal model, which was decomposed to the rest of the goals and encapsulated the overall purpose of the module. This was performed for reasons of completeness and comprehensibility of the goal model by stakeholders and had no further impact on the rest of the approach. Another point requiring further attention is the inadequacy of goal models to capture the exact sequence by which their (sub-)goals should be accomplished, especially when complex branching (e.g., inclusive, exclusive gateways) is present at the process model. This led to the need for some manual intervention during the fifth step of our transformation algorithm, as explained in the previous section. To address this issue in the future, extensions at the notation of Secure Tropos will be explored, along with the refinement of the transformation rules defined in the algorithm.

5 Conclusion

The modernisation of enterprise legacy systems can be a demanding and time consuming endeavour. In order to facilitate that process, the MARBLETM framework has been developed for the extraction of process models from legacy source code. Such process models offer a more comprehensible and flexible platform for the elaboration of potential redesigns of the legacy system in question. The IBUPROFEN framework was also developed since the extracted process models often required some refinement (e.g., removal of excess notation, completeness).

In this work we extend these frameworks by introducing an algorithmic approach for the transformation of the derived business process models to goal models. Goal models provide the means necessary for the elaboration of security for the redesigned legacy system, at a high abstraction level, comprehensible by non-technical stakeholders and aligned with organisational objectives. Using a set of transformation rules, goal models can be created based on such business process models. Secure Tropos offers the means for capturing the security related aspects of the redesigned system (e.g., security constraints, mechanisms, threats), which can then be incorporated back into the process model via a set of goal-to-process transformation rules. As a result, security choices of the system’s stakeholders can be operationalised by the redesigned business processes.

An illustrative example of a legacy system module was utilised as a proof of concept for the proposed transformation approach and led us to useful conclusions about its completeness and effectiveness. Its application resulted in an accurate goal model representation of the selected legacy system’s module, upon which security was successfully elaborated and then introduced back into the process model. Some complications sourced from certain elements of process models (i.e., sequence of execution, branching) which cannot always be translated to goal modelling concepts without losing certain information. Nevertheless, this example provided valuable insight on the applicability of the proposed approach while it also brought into consideration aspects which require further attention.

Overall, this novel approach could be a valuable tool for both practitioners and researchers, attempting to introduce security to existing business processes, starting from a high level of abstraction, which allows the alignment of security choices with the overall organisational strategy. Despite the emphasis in business processes extracted from legacy source code, the transformation algorithms introduced by this approach can be utilised for the introduction of security to any available process model, newly designed or already existing. This approach will also be integrated in the extraction activity of a migration process of legacy systems to the cloud (SMILE2Cloud) in which we are currently working [37, 38].

Future work will look into the formalisation of the existing transformation algorithms using QVT and the potential addition of further steps or activities in order to eliminate any flaws during the transition between goal and process models and vice versa. As soon as a set of concrete transformation rules has been explicitly defined via an appropriate formal language, already existing support tools (e.g. SecTro tool, Eclipse plugins) can be further extended to automate the majority of this transformation, thus limiting the need for manual intervention. Finally, the validation of this approach via a case study would add great value, especially if it involves a large and more complex enterprise legacy system along with the participation of its stakeholders and analysts.