BPM y Requerimientos no Funcionales

BPM ( Business Process Management ) has emerged as a technique for modelling and specifying such business processes. Similarly, languages ​​and tools such as BPMN ( Business Process Model and Notation ) and BPEL ( Business Process Execution Language ) have established themselves as the most widely used tools for implementing a SOA architecture with well-defined business processes.

However, a problem has been detected in the software development community related to the specification of non-functional requirements. Requirements such as availability, performance, security or modifiability, whose behaviour is key and defines the success or failure of an SOA architecture, are not correctly specified in BPM. This has the consequence that they are not appropriately added to the specification of business processes, with the consequent threat to an SOA architecture that is guided by these processes.

Different proposals have emerged to alleviate this problem [1,2]. The main aspects of these proposals are described below, the main objective of which is the incorporation of non-functional requirements in the description of business BPM processes in a SOA architecture.

Adding non-functional requirements to BPM

The first proposal incorporates them using the usual BPM mechanisms through a special type of annotations, while the second defines new artifacts for modeling. Each of the proposals is described below.

Non-functional requirements through annotations

The proposal presented in [1] consists of adding non-functional requirements as annotations to the activities that describe a business process. Such annotations are called “QoS” ( Quality of Service ) artifacts. Through them, availability issues can be introduced (for example, an activity that needs to be available all the time), security issues (for example, an activity where data protection and confidentiality are needed), performance issues (specifying the maximum time that an activity can take). The following figure schematizes the proposal, illustrating the specification of a performance requirement.

Figure: Annotating non-functional requirements as annotations

Finally, these QoS artifacts are encoded using the WS-Policy standard [3], which allows introducing restrictions to the behavior of services in an XML format. For the example in the figure, the restriction to be introduced would be:

<Performance max_runtime_minutes=»15″/>.

Given this scenario, non-functional requirements can then be implemented in some of the available BPEL tools, such as these , or these others . Then, in this simple way, non-functional requirements can be specified in BPM diagrams.

Non-functional requirements with new constructors

The proposal in [2] attacks the problem in a different way. Instead of using annotations, it considers more complex artifacts to give more value to the non-functional requirement. The disadvantage is that a new tool must be obtained to implement and transfer the proposed knowledge for commercial use.

The technique proposes to accompany the description of a BPM activity with two new terms: Operating Conditions , and Control . Control conditions declaratively establish the conditions necessary to develop the activity, whether they are security, performance, or any other non-functional requirement. The control part captures the business risks associated with the operating condition, and the business controls to be performed to mitigate the risk. One of the examples presented in [2] addresses the non-functional security requirement within the context of an ATM (but is easily transferable to another domain). The activity of calculating the balance of an account operates under certain operating and control conditions. Control conditions simply establish that data must be handled with confidentiality and integrity, since they are sensitive data. The control part can be detailed with the following table:

Conclusions

Two techniques have been presented for adding non-functional requirements to BPM. The first one does not introduce new terms, but is more limited in scope. The second approach is more powerful, but requires new tools to implement the corresponding artifacts. A reasonable approach is to use the simplest option first, and then use the second option if more expressive power is needed.

References

[1] Oliver Charles -Bernhard Hollunder ICSEA 2011: The Sixth International Conference on Software Engineering Advances .

[2] Christopher J. Pavlovski and Joe Zou. 2008. Non-functional requirements in business process modeling . In Proceedings of the fifth Asia-Pacific conference on Conceptual Modeling – Volume 79 (APCCM ’08), Annika Hinze and Markus Kirchberg (Eds.), Vol. 79. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 103- 112.

[3] W3C, Web Services Policy 1.5 (09/2007) – Framework, Retrieved April 03, 2011.

Image: Alexandra Cavoulacos (Flickr under CCommons license)