Keywords

1 Introduction

Many companies, especially large companies, model their organizational processes and software systems. This is to define and improve them, identify and reduce flaws. Explicit models of processes and software architectures not only enable their analysis and optimisation, these models also save costs during the evolution of processes and software architectures. However, business and software system experts typically use different modelling languages. There exist many languages for modelling business processes. BPMN, a semi-formal notation, is the most prominent one. Petri nets provide a formalized view of processes. Transformations which establish mappings between BPMN and Petri nets exist. In the following, we focus primarily on Petri net [1] models and consider BPMN only marginally. The state-of-the-art modelling language for software systems is UML [2]. As neither business process modelling languages nor UML have elements capable for modelling privacy, extension mechanisms exist for introducing additional symbols to model various aspects of privacy. Additionally, security is also relevant because privacy is related to some security goals such as confidentiality or integrity. Both security and privacy are becoming increasingly important, for example due to the upcoming General Data Protection Regulation (GDPR) [3].

Although there are many approaches to extending business process modelling notations and UML to cover security and other aspects, there is no common and generally accepted approach for modelling privacy. A broad variety of approaches exists for introducing additional symbols to model privacy directly or indirectly, through security elements. However, the extent to which privacy can be modelled depends on the proposal. Additionally, modelling approaches which support transformations from business process models to software design to keep business process models like Petri nets and software models like UML consistent with each other are missing. Due to these reasons, we analysed the capabilities of existing software architecture-oriented and business process-oriented modelling approaches to model privacy aspects. We analysed, how privacy can be modelled and investigated the possibility of and need for a comprehensive modelling language in the field of privacy to cover business processes and software systems. We selected these approaches according to their abilities to model privacy aspects directly or indirectly, through security aspects. The selected approaches were analysed and compared with each other to identify their similarities and differences. This was done to understand the need for a comprehensive model of privacy aspects and to explore how it could be realized, beginning from a business process model and then leading to a software architecture model. For this, we categorized the approaches and identified two criteria, namely “security mechanisms” and “different views”. “Security mechanisms” describes the elements and mechanisms by which the approach supports privacy modelling. The second criterion, “different views”, groups approaches according to the view of the stakeholder for whom the approach is intended. Our results show that only a few approaches actually introduce elements to model privacy principles. In the following Sect. 2, we describe why the needs for a holistic modelling approach is increasing. Section 3 presents the business process-based approaches. Software architecture-based approaches are presented in Sect. 4. Section 5 discusses similarities and differences between both approaches. The contribution ends with some concluding remarks in Sect. 6.

This paper is an extended version of a paper presented at the 4th International Conference on Information Systems Security and Privacy in 2018 on Madeira Island, Portugal [4]. The expansion consists in particular of the new Sect. 2 (Increasing Need for Holistic Modelling) and a further developed and more detailed conclusion.

2 Increasing Need for Holistic Modelling

In the past few years, companies have faced the increasing problem of cybercrime [5]. Cybercriminals are becoming more organized and cooperating in larger groups, allowing them to undertake more and more complex attacks. Companies also face a growing number of security laws with which governments require them to comply. Especially companies that operate globally have to comply with the laws of different countries. To state some of them, the Basel Accords and Minimum Requirements for Risk Management (MaRisk) [6] regulate the risk management for the finance sector; the IT Security Act [7] regulates the security of IT systems for critical infrastructures; and the General Data Protection Regulation (GDPR) [3] governs data collection, processing and the use of personal data in the European Union. However, privacy regulation is not new. In 1970 the first formal worldwide data protection law came into force in the German federal state of Hesse [8], in 1984 the Bundesverfassungsgericht (Federal Constitutional Court) created the basic right of informational self-determination based on the general right of personality (Art. 1(1) and Art. 2(1) German Grundgesetz [Basic Law]) [9] and in the European Union, a 1995 European directive set the framework conditions for the processing of personal data [10]. But the GDPR imposes financial penalties of up to 20.000.000 Euro or if higher four percent of an organization’s worldwide turnover, which is similar to other regulations.

The business of companies is becoming more complex every year. Supply chains and manufacturing are increasingly distributed all other the world and operate in complex ecosystems. Thus, companies face the complicated task of developing rules and standards in order to protect their sensitive personal data and business secrets according to their needs. They are of the utmost importance, as only the business level of a company knows which data are critical and their required level of protection. Altogether, we see that IT security is becoming more and more crucial for companies of all kinds. That is why the business level is charged with several additional goals pertaining to IT security. Firstly, to prevent cybercriminal attacks, reputational damage and consequently the loss of monetary income, they have to establish organization-wide IT security. There are various guidelines like the ISO/IEC 27000-series [11] or the IT Baseline Protection [12] which describe how to establish, manage and maintain information security effectively in organizations. Access control requirements from the business level perspective are described there too. Guidelines like ITIL [13] or COBIT [14], which comprise sets of practices for IT service management, introduce dedicated business processes for IT security and access control. Therefore, establishing organization-wide IT security is a complicated task involving different departments and various models. Secondly, during the establishment of organization-wide IT security, companies have to comply with an increasing number of security laws. This means that the compliance department is a fundamental part in the whole process. Thirdly, as only the business level knows which assets need to be protected, they have to define the rules and standards on how to interact with these assets. To sum up, the business level in a company becomes a key point in establishing security and privacy and therefore has to work closely with many different departments like IT and compliance departments, resulting in diverse models relevant for IT security and privacy. Thus, there is a need for a systematic transformation between these models to keep them consistent with one another. Only in this way can a good alignment can be realized.

IT security and privacy has become crucial for all kind of companies. One thing IT security and privacy have in common is the need for access control requirements. Both IT security and privacy impose access restrictions on certain data. While IT security describes principles, algorithms and protocols on how to restrict access, privacy describes who should have access to which personal data and how to handle it. These access control requirements come partially from security laws and security guidelines. The business level establishes the other part in terms of rules and standards, as described above. They are both modelled increasingly in business processes, due to the obligation or decision of companies to implement IT service management guidelines like ITIL or COBIT. IT departments must adapt these access control requirements such as enterprise architectures, system architectures and so on in their own models. A typical modelling language here is UML [2, 15]. Different knowledge about terminology is a problem and creates a communication gap that opens up the potential for errors. This poses a severe problem, because any error can undermine security. Thus, both the IT department and the business level have an interest in keeping their numerous models consistent, so that access control requirements are implemented correctly and consistently.

Often, the fact that companies are evolving is neglected. This means that systems, requirements, business processes, enterprise architecture and other models steadily evolve. They all have a lifecycle and affect each other in non-trivial ways [16]. Their complex interrelations are not understood well and have not yet been adequately researched [16]. As stated above, problems here may lead to security breaches. Hence, there is the need for a fast and automatic transformation between the models to keep IT security and privacy information correct and consistent. Additionally, it is important to understand the mutual dependencies so that the various departments can react to changes. Traceability between the models can help, since it allows tracing and understanding design decisions. Both traceability between business and IT models and their mutual interdependence are not yet well researched.

Access control requirements formulated in law and in guidelines must be incorporated and extended by the business level and then implemented by the IT department. There is a need for a transformation between all models of the involved parties. Considering the increasing number of companies implementing guidelines like ITIL and COBIT, as well as the close collaboration between the business level and the compliance department, business processes today comprise many access control requirements. These business level access control requirements represent the demands of law. A promising way to close the gaps described above would be to extract the access control requirements from business processes and transform them to the various models of the IT. Enterprise architectures offer the right granularity and could be analysed as to whether they comply with the extracted access control requirements by using a data flow analysis. Another possibility is to transform the access control requirements directly into permissions for an access control system. Clearly, the increasing need opens a large and promising field of research for transformation and consistency problems between models of different areas.

3 Software Architecture-Oriented Approaches

This chapter introduces the software architecture-oriented approaches for modelling privacy. The first section gives a brief introduction to the de facto standard modelling language in the field of software engineering and the second section is an inspection of the architecture-based approaches in the context of privacy and confidentiality.

3.1 Modelling

The Unified Modelling Language (UML) is the current standard for modelling architecture in software engineering. De facto UML is a general-purpose language which is standardized by the Object Management Group (OMG). It comprises 14 diagrams divided in two major diagram types: structure diagrams and behaviour diagrams [2]. While structure diagrams mainly focus on illustrating the static structure of a system, behaviour diagrams point out its dynamic part. The sequence diagram shows the chronological flow of messages between objects. It brings an additional technical dimension to the practice and is an integral part of the described static structure. The use case diagram visualizes functional requirements, including the different actor groups and their suitable participatory methods or relationships. Class diagrams describe classes, associations, methods and their attributes. This is a short overview of the modelling diagrams in UML. A detailed explanation can be found in the UML specification [2].

3.2 Analysis of Software Architecture-Oriented Approaches

This section surveys the software architecture-based approaches. Table 1 summarizes all analysed papers, the types of UML diagrams used, whether they extend through UML profile or not, and what the extension allows to be modelled.

Table 1. Overview of software architecture-oriented approaches [4].
Full size table

[17] propose an extension to the UML use case diagram for representing privacy specifications like pseudonymization, anonymization and consent in an easily understandable way (see Table 1 no. 1). The extension is not based on the UML profile extension mechanism. Instead, a Microsoft Visio extension ribbon is created that offers the required elements. All possible privacy requirements and specifications can be expressed due to the use of free text fields. Furthermore, in use case diagrams the extension works by introducing a ‘super container’ in-between actors and use cases. Privacy control classes and obligations are stated inside the super container. This extension enables it to express all kinds of privacy principles and allows a technical specification of other security principles like confidentiality. [18] introduced a UML profile which is capable of expressing different privacy concepts through privacy policies incorporated in various UML diagrams (see Table 1 no. 2). Privacy policies are composed of one or more statements which describe the rules specified in the privacy policy. Besides that, they also specify the purpose of data collection, its management, and the prerequisites that need to be met. Private data and actions performed on it can be aggregated and translated into standardized stereotypes to, for example, identify to whom the access to private data is granted, the period, and the usage behaviour of the target groups. Several other stereotypes describe how the data are provided and managed, either by a user or by a system. In both cases, the UML profile allows the design of privacy-aware applications by modelling the application’s privacy policy and keeping track of the elements responsible for enforcing it. The profile not only allows modelling of access control on private data, but also of privacy principles like consent, data security and purpose limitation.

[19] proposed a UML profile, called UMLSec, which is shown in Table 1 no 3. It is specifically constructed to express security-relevant information within various UML diagrams. In particular, it enables non-experts in the area of security to express their security needs easily. UMLSec enables software engineers to express basic security requirements including security concepts, security primitives, security management and threat scenarios. This allows modelling of confidentiality of information and information flows. Furthermore, it is possible to check whether the constraints associated with the stereotypes are fulfilled by a given specification and, by this, indicate possible vulnerabilities [20].

[21] present a UML profile with a decentralized label model incorporated into UML class diagrams (see Table 1 no. 4). This allows the modelling of confidentiality at design time. The so-called UMLs profile allows the specification of confidential information flow in a fine-grained manner. Different stereotypes defining owners and users are used to annotate classes, attributes, operations, parameters, errors, and return types. These labels are used to decide whether the information flow is permitted or not. Declassification of information is realized with the authorityConstraint. It models the weakening of the confidentiality of information coming from more confidential sources. This is necessary for operations processing confidential data but providing less confidential results. The approach is presented for class diagrams, but it is extendable to other diagram types such as interaction, use case and activity diagrams.

The work of Goudalo et al. [22] elaborates on modelling security aspects of information systems (see Table 1 no. 5). They propose a UML profile on how to properly encapsulate security knowledge during design time. An example is shown in the context of confidentiality. Confidentiality of information and information flow is modelled in sequence diagrams by defining stereotypes modelling the confidentiality levels of resources, subjects, and subsystems. In essence, software engineers are able to model confidentiality in diverse ways by using this UML profile.

Table 1 no. 6 shows the work of Hatebur et al. [23]. They build upon a UML profile for expressing problem frames in UML class diagrams. Problem frames are patterns are used to define problem classes by their contexts and characteristics. The extended UML profile expresses dependability requirements. In the case of security, the traditional goals of confidentiality, availability and integrity can be expressed. These goals are modelled with stereotypes and include specifications like the data to be secured, the attacker and the stakeholder of data. Additionally, problem frames allow the expression of arbitrary confidentiality requirements. The authors mention that the main advantage of their approach is the ability to express dependability requirements without the anticipation of a solution. This clearly separates the problem space from the solution space. Furthermore, it is easy to visually distinguish between different security requirement classes.

The approach of [24], SECDW allows the modelling of confidentiality aspects in UML class diagrams (see Table 1 no. 7). SECDW is an extension intended for the domain of data warehouses. The approach introduces a UML profile that enables the specification of security classes for information and users. Tuples composed of security classifications, sets of user compartments (classification of users in department like structures), and user roles allows the specification of constraints about which users are allowed to read certain information. Triki et al. [25] proposes an extension (SECDQ+) with the ability to model leaks of confidential information. Examples are health information or company turnover which, if accessed in combinations of datasets, leak additional undesired information. This problem is known as conflict of interest [25].

The UML profile of [26] is capable of both capturing security requirements and specifying security solutions (see Table 1 no. 8). This is achieved by placing security aspects into UML class and sequence diagrams in an aspect-oriented modelling manner. Besides that, the approach allows the expression of the separation of security concerns for software functionalities. Security experts can specify security solutions as aspects in the UML model and model their points (where the security solutions are implemented) in UML sequence diagrams. In consequence, the solution is easily understandable even for non-security experts.

The UML profile of [27] models privacy restrictions in UML class diagrams (see Table 1 no. 9). The target field is in the context of mobile distributed systems, but the approach can be used in other contexts as well. The main idea is to bind access rights to context information. This is done by formulating privacy restrictions on context information. Privacy restrictions are composed of the source and validity of the context information, as well as the access rights in the form of confidentiality levels. In Simons’ UML profile, constraints are used to validate the model. This is accomplished by imposing restrictions on the defined stereotypes to enforce the correct use of the profile.

4 Business Process-Oriented Approaches

Privacy and security are business requirements, and therefore privacy as well as security requirements are increasingly included in enterprise modelling [28]. This can be achieved in different ways:

  • via models of privacy and security aspects using normal enterprise modelling languages

  • in the form of annotations

  • with the help of more-or-less formalized privacy/security notation add-ons for existing modelling languages

For business processes as one component of enterprise modelling, we analysed ‘Petri nets’ and ‘Business Process Model and Notation (BPMN)’.

4.1 Analysis of Petri Net-Based Approaches

There are plenty of approaches to using Petri nets for modelling information security aspects, particularly information confidentiality. They can be used to model privacy requirements as well, but special privacy model extensions are not common today. The problem is that some of the approaches only focus on the technical level, which generally means that they are discussing problems like algorithms, protocols or technical architecture, using Petri nets for visualisation, but omit the business process perspective.

Huang and Kirchner have introduced a formal method to verify whether the compositions of sub-policies fulfil the required general policies of a company [29]. They used coloured Petri nets and Petri net-based properties like completeness, termination, consistency and confluence. One use case is the verification as to whether a set of policies fulfils a general policy like GDPR. Therefore, the requirements of the GDPR must be transformed into a model.

[30] extended object Petri nets by using modules to define security services like the decryption and encryption of data. This could be interesting for data protection because encrypted data need not be protected itself as long as the key is strong and kept secret. [31] defined a framework for the assessment of security protocols. They used coloured stochastic activity nets and implemented probabilistic model checking. In addition, [32] analysed security protocols and a Petri net extension called S-net, which is designed such that the terms of the Security Protocol Language [33] can be used. Other Petri net-based approaches aim at building models for special concepts. For example, [34] modelled the Chinese wall policy with coloured Petri nets; afterwards, they used a coverability graph to analyse the guarantees of the Chinese wall policy. [35] used coupled Petri nets for the risk analysis of computer networks. Sun et al. published a ‘Verification Mechanism for Secured Message Processing in Business Collaboration’ [36]. They used the role-based access control (RBAC) mechanism and hierarchical coloured Petri nets to detect conflicts in message access within collaboration process instances to the role-based policy. A similar approach from [37] focused on the confidentiality of information exchanges between organizations and therefore has special places in coloured activity nets for incoming and outgoing information. Chinese wall and interorganizational information exchange are also relevant for privacy protection questions. As shown, many approaches use Petri nets for modelling security aspects, but focus on a technical level or only cover one single aspect. Therefore, these approaches are not suitable for use by business process experts to model their security requirements and discuss them with technical experts.

In addition, some approaches use Petri nets for modelling or analysing security aspects of business processes. Accorsi and Wonnemann developed InDico [38], an information-flow analysis method for labelling Petri net-based business process models. InDico focuses on ‘information propagation throughout the systems (end-to-end) rather than mere data access (point to point)’ [38]. Accorsi et al. [39] published an extension of InDico for analysing information-flow effects during process execution. They used security levels (called ‘levels of confidentiality’) but reduced them to two, and analysed the structural interferences between them. It is impossible to express different levels of confidentiality for the same place in one business process scheme, e.g., different information, or more than two levels of confidentiality for the whole business process scheme. Li et al. [40] described a coloured Petri net extension for detecting confidentiality problems in information-flow models. They use security levels and add the concrete security levels as attributes of the tokens. Li et al. did not focus on the resources handling the information. Knorr [41], who also used security levels, presented a method to verify multilevel security policies in workflow models, but he modelled control and information flow as different arcs in his workflow Petri nets. Atluri and Huang [42], who have also used Petri nets, presented a multilevel security approach with security levels for places and tokens. They later extended their approach with more concepts, like separation of duty and role-based access, using a coloured, timed Petri net [43]. They did not consider resources or the possibility of reducing the security level of a token, e.g., when information is truncated.

The large number of approaches for modelling security aspects using (high-level) Petri nets shows that the integration and processing of confidential information in Petri net-based business process models is currently a major challenge. This is one reason why we think Petri nets are also suitable for privacy questions. Other reasons in favour of Petri nets are their mathematical foundation and the availability of a broad range of analysis methods. Especially for analysis functionality, formal Petri nets are necessary.

4.2 Analysis of BPMN-Based Approaches

Extensions of the Business Process Model and Notation for modelling security requirements exist for each of the three classic security objectives: confidentiality, integrity and availability. Leitner et al. [44] have published a systematic literature review on ‘Security Aspects in the Business Process Model and Notation’. Therefore, we do not provide a detailed overview here. In summary, some publications use BPMN for security questions without new extensions. In [45], Meland and Gjaere argue that there is no need for new BPMN extensions for many questions. Several other approaches extend the BPMN notation, e.g., with new symbols to create a faster overview of security issues for the model users [46]. Focusing on privacy as part of security, [47] used BPMN to introduce privacy in business process models, while Labda et al. [48] extended BPMN to privacy-aware BPMN. They focused not only on modelling privacy aspects, but also proposed a methodology for transferring them into the implementation.

5 Comparing Approaches

We have identified two criteria through which the software architecture-oriented and business process-oriented approaches can be conceptionally compared. In summary, only a few approaches we reviewed introduced elements to model actual privacy principles [17, 18, 43]. Most of them introduce privacy as a way of establishing confidentiality and restricting access to information.

5.1 Security Mechanisms

This criterion describes the expression of privacy in models in terms of how it is expressed, and through which security and privacy mechanisms it is represented. We recommend the following two characteristics for an analysis:

  • Information flow and access control: this characteristic establishes privacy by introducing concepts that restrict the information flow or the access to information, functions or system parts by imposing rights. Approaches with this characteristic introduce concepts of confidentiality in various ways as well as in different degrees. These concepts are used either directly or can be used to express privacy in a certain way. Examples are Chinese wall policy and confidentiality levels. The following approaches fulfil this characteristic [19, 21, 22, 24, 27, 34, 36,37,38,39,40,41, 43, 47].

  • General structures: approaches with these characteristics use abstract structures to express either several or a particular security and privacy principle. An example is the problem frames of [23] which provide the ability to express a problem and, through this, express an actual security principle. Another example, common in the security area, is policies. We identified the following approaches fulfilling this characteristic [17, 18, 23, 26, 29,30,31,32, 35, 43].

Each approach is assigned to one of the above characteristics. The approaches we reviewed focus either on the key feature of confidentiality to express privacy, or on introducing various other structures through which privacy is expressible. The first are grouped under the characteristic ‘information flow and access control’ and the latter ones under the characteristic ‘general structures’. Our analysis shows that nearly half of the reviewed software architecture-oriented and business process-oriented approaches fulfil the first characteristic. They all introduce elements to model confidentiality. Some of them additionally use confidentiality mechanisms to establish privacy in a specific way [24, 34, 36,37,38,39,40,41]. The other approaches of the first group only introduce modelling elements for confidentiality. These modelling elements are not directly for the purpose of expressing privacy [19, 21, 22, 27, 47]. The other half of the reviewed approaches utilize various other mechanisms to model privacy. The approach [17], for example, introduces new structures like super containers and problem frames to express privacy. Some others use policies [18, 19].

5.2 Different Views

This criterion distinguishes the approaches according to their view on the model. As there are various stakeholders with different concerns to express, different views arise that fulfil the needs of a specific stakeholder. Typical examples from the field of security are the attacker view and security specialist view. The attacker view introduces model elements showing how the attacker could break into the system. The opposite side highlights the security measures in place, namely the security specialist view.

The criterion ‘different views’ divides the approaches according to the needs of their stakeholders. Common views are:

  • Attacker view: models the attacker with the attacks, threats and vulnerabilities of a system, or analyses the given model for flaws in the information flow [19, 31, 32, 35, 38,39,40, 43].

  • Requirements & Implementation view: introduces elements to express requirements pertaining to security and privacy aspects and elements, which model security and privacy solutions [17, 18, 21,22,23,24, 26, 27, 30, 34, 36, 37, 43, 47].

  • Verification view: allows users to check whether a model fulfils certain requirements by checking them against the model. This is realized, for example, with constraints, which are checked for correct implementation, or the verification of policies [18, 21, 24, 29, 34, 39,40,41,42].

The software architecture-oriented approaches realize the ‘attacker view’ by introducing an attacker with his capabilities. We found only one approach of this type in our analysis [19]. The business process-oriented side identifies flaws in the information flow, and thus privacy breaches. Both the software architecture-oriented approaches and the business process-oriented approaches are represented in the ‘requirements & implementation view’. Here, elements are introduced to express security and privacy requirements or solutions. The difference in these approaches lies in the degree of abstraction. While the business process-oriented approaches are typically on a less technical and more abstract level, the software architecture-based approaches introduce both a non-expert view and, sometimes, a more technical, expert view. In both software architecture-oriented approaches and business process-oriented approaches, we identified the intention to verify whether the implementation or model is correct with respect to certain requirements. These approaches are part of the ‘verification view’. While software architecture-oriented approaches verify the correctness of modelled solutions, business process-oriented approaches try to identify and verify security policies against a given model. In general, we recognized that, for the reviewed approaches, the software architecture-based approaches tended to model requirements or design solutions more often. They also had a stronger focus on verifying whether the model fulfils the requirements. The business process-based approaches had a stronger focus on the identification of flaws and the verification of policies.

6 Conclusion

As we have shown, there are some approaches to systematically modelling security and/or privacy aspects of organizations each from a specific perspective. However, no comprehensive approach integrates all aspects such as process, structural organization and data. Such approaches must be developed or further developed. Figure 1 illustrates the relationships between companies and enterprise software (as the origin of models), sent model types and views, as well as the implemented software, the implemented processes/structure and the people involved. The arrow shown between origin and model describes a mapping function. Dotted arrows describe influences between different original models or artefacts. Different models exist for a company (the model origin at the top of the figure). For the view Business Process Flow Models, for example, Petri Nets and/or BPMN models exists. For this purpose, we have drawn in a new integrated view, information security/privacy. This includes various other views and their models and integrates them in an appropriate manner. Appropriate links must be developed for this purpose. For example, you need to describe which organizational unit participates in a particular activity of a business process, and to determine whether the organizational unit is allowed access to the data that is also linked to the activity. In addition to this linking of existing views, an integrated view can further enhance the models (for example, by providing additional information on data protection, such as the purpose of an activity to check the purpose limitation of the data). Such an integrated view is currently not sufficiently developed for the Information Security/Privacy application case, as literature research has shown. However, approaches and concepts already exist (such as the concept modelling suites, a concrete implementation of which is, for example, the Horus Business Modeller, www.horus.biz), on the basis of which this integrated view was developed. Integrated views means that models from different views are linked together and consistency is enforced.

Fig. 1.
figure 1

Holistic modelling approach.

Full size image

This integrated view describes the requirements of those responsible for the company software. These requirements of the enterprise models must be transferred into the software models to be implemented later. However, software engineers use other models (e.g. UML) to describe the requirements.

Nevertheless, traceability of the requirements must be guaranteed. A systematic and, as far as possible, automatic transformation of the requirements is therefore required. This is shown in Fig. 1 by the dashed line between the company models and the software. Here, it is necessary to derive an integrated view for the middle part of the illustration from the integrated view of the upper level. We therefore suggest an automated model transformation from enterprise to software modelling. Continuous modelling is a prerequisite for the traceability of the requirements. Therefore, it must be possible to transfer business requirements modelled in Petri nets to software requirements modelled in UML.

The arrow between enterprise software and the enterprise in Fig. 1 shows that standard software influences enterprises as well. The arrow between the company models in their entirety and the implemented processes/structure describes the influence of modelling on subsequent execution. The connection between the software models as a whole and the implemented software is also shown by a dashed arrow. Finally, implemented software and implemented processes (which can also be partly manual)/implemented structure influence each other in terms of execution properties such as efficiency. The people involved are also affected or influence the concrete use of the software, or compliance to the processes and structures.

That there is currently no comprehensive modelling approach which covers the necessary aspects and perspectives. This should include processes as well as, for example, organizational and data structure questions. Therefore we suggest a new holistic modelling approach which includes the needed aspects and with a concept for the traceability of the requirements from business models to software architecture models. The new approach uses modelling languages and methods of existing approaches. To get a holistic view we linked them (different views and languages) and enriched them for the purpose of privacy and security modelling.