# Advanced Approach to Future Service Development

Tetiana Kot, Larisa Globa, Alexander Schill

► To cite this version:

Tetiana Kot, Larisa Globa, Alexander Schill. Advanced Approach to Future Service Development. 19th Open European Summer School (EUNICE), Aug 2013, Chemnitz, Germany. pp.233-244, 10.1007/978-3-642-40552-5_21. hal-01497020

HAL Id: hal-01497020

https://inria.hal.science/hal-01497020

Submitted on 28 Mar 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Advanced approach to future service development

T.Kot, L.Globa, A.Schill

National Technical University of Ukriane «Kyiv Polytechnic Institute», Ukraine,
Technische Universität Dresden, Fakultat Informatik, Deutschland

**Abstract.** Modern companies, including telecommunication ones and mobile operators, working in the global environment, need to guarantee technological effectiveness and innovation, renewing their technologies and services. Communication technologies and variety of services are to be improved and developed extremely fast. This results in the need for constant adaptation and reconfiguration of complex software systems, used in global environment to provide and monitor deployed services. For instance, OSS/BSS is used in the domain of telecommunication companies. Reconfiguration of complex software systems covers application development for service provisioning, their dynamic monitoring and reconfiguration. Currently, system adaptation and service design strategies are poorly formalized and validated. In current state-of-the-art approaches, several iterations involving analysts and system architects are necessary, resulting in time and money consuming service development. The approach proposed in this paper fills this gap. It employs a well-defined workflow and analysis model for developing and adapting complex software systems. The applicability of this novel approach is confirmed by an implemented software tool. The proposed approach and tool provide automation of service development, focusing on planning and design stages, considering both functional and non-functional requirements and realizing computational independent workflow transformation into its execution model.

**Keywords:** service development, OSS/BSS, non-functional requirements, workflow design and transformation, Dia editor.

## 1 Introduction

Today, companies, working in global environment, constantly renovate and improve their technologies, providing services by web-oriented applications [1]. This is realized via service development and re-engineering. Companies tend to minimize time of service provision, constantly improving communication technologies and applications. Thus, means and tools for fast workflow design and reengineering during system runtime and for providing services within a minimal time are in high demand.

The lifecycle of service development is an iterative process, consisting of the following stages:

1. workflow design: development and description of computation independent and computational workflows, including service planning, applications prototyping;
2. workflow analysis and simulation, considering several system parameters;

3. workflow enactment, providing deployment models, considering both hardware and software service deployment alternatives;

4. service/workflows monitoring, leading to services re-configuration.

Currently the service planning stage is performed manually. This does not result in optimal solutions because a lot of factors have to be considered when planning differentiated services [2]. Furthermore, in the current state-of-the-art computational independent workflow design, being performed using existing notations and tools on one hand all required parameters, necessary on the service planning stage, such as numerical values of execution time and resources, and also document and information flows, supporting service provision, are not considered and on the other hand poor connection to system functionality, realizing these workflows are provided.

When service design and deployment, an important aspect concerns NFR<fnref n="1" /> to service provision. It is extremely important to meet NFR on design stage, otherwise provided service may be useless in practice.

Currently, NFR are not considered with perspective of provided services list as legacy methods can design service according to NFR, but cannot model an influence of concurrent services on particular NFR because of collaboration between services. There are also no tools allowing flexible balancing between services.

Transformation processes between workflow modeling stages is still an open question, though there are transformation standards and languages [3], but this issue is not fully automated and has to be investigated to make service design correct.

This paper describes an advanced approach to future service development, including novel computational independent workflow design method, NFR balancing method and modified service workflows transformation method.

The paper is structured as follows: Section 2 contains state of the art analysis of workflow design notations and tools. State of the art analysis of methods and approaches to considering NFR. NFR analysis methods and service implementation technologies are described. BPMN to BPEL transformation strategies are also considered.

Section 3 introduces advanced approach to service development. It includes workflow design method, focusing on two core aspects: a computational independent workflow model and workflow analysis method, providing service provisioning time minimization; NFR balancing method, focusing on functional and non-functional requirements collaboration; modified service workflows transformation method.

Section 4 presents a prototypical realization of the advanced approach, including design and transformation tools and highlights evaluation results of the developed tools. The evaluation has been applied using a real-world scenario within a telecom-munication company.

Section 5 concludes the work with a summary and outlook on future work.

<footnote n="1">¹ Non-functional requirements</footnote>
# 2 State of the art and Background

## 2.1 Workflow design notations and tools

Service planning is defined by finding a good way to create service provision at minimal time, having specific resource values as a limitation. In the following a summary of the state of the art of the central areas of this overall field will be discussed. A state of the art analysis of workflow design notations and tools, workflow analysis methods and systems, parameters, which should be taken into account at the planning stage and NRF design methods are presented.

### Computational independent workflow design.

Computational independent workflows are designed using graphical standards, allowing their formalization in a diagrammatic way. Analysis has shown that in practice computational independent workflows are usually designed using graphical notations such as BPMN 2.0², UML AD<fnref n="3" />, USLD<fnref n="4" /> and tools such as CA ERwin Process Modeler<fnref n="5" /> and Enterprise Architect<fnref n="6" />.

The main criteria, used when analyzing current state-of-the-art notations and tools for computational independent workflow design, are possibility to consider and analyze several parameters, necessary on the service planning stage, such as service provision time and resources, and on the other hand provide connection to system functionality, which should realize these workflows.

USDL doesn't meet all the requirements of workflows analysis and design, its usage is difficult due to its complexity, in spite of its comprehensiveness.

The main argument against using regular BPMN is that management of resources can be expressed only via lanes (actors, roles, etc.) or performers of user or manual tasks [4], when execution time parameters are not considered. All further existing workflow modeling notations have this core criticism in common.

Nevertheless, BPMN, providing computational independent to computing workflows transformation (BPEL<fnref n="7" /> diagrams), was applied as a basic notation for computational independent workflow design, being extended with added missing concepts [5].

### Workflow analysis.

The overview of the workflow analysis methods and tools has shown, that there exist two types of analysis, both considering computational workflow [6]:

1. Design time analysis (simulation and verification);

2. Runtime analysis (i.e., process mining, based on the execution logs).

<footnote n="2">² http://www.omg.org/spec/BPMN/2.0/</footnote>

<footnote n="3">³ UML Activity Diagram</footnote>

<footnote n="4">⁴ http://www.internet-of-services.com/index.php?id=264</footnote>

<footnote n="5">⁵ http://erwin.com/products/detail/ca_erwin_process_modeler/</footnote>

<footnote n="6">⁶ http://www.sparxsystems.com/products/index.html</footnote>

<footnote n="7">⁷ Business Process Execution Language</footnote>
Software tools such as Cactus, ASKALON, GLUE, etc. [7] are used for these analysis fields. Mentioned and analyzed current possibilities for this task stage are very limited. Shortcomings of workflow analysis methods and tools are clearly described in [8]. The central criticism is that the requirements analysis stage is applied mainly in a manual manner.

## 2.2 Methods and approaches to considering NFR

Early-phase requirements engineering should address organizational and NFR, while later-phase engineering focuses on completeness, consistency and automated verification of requirements. Not proper dealing with NFR leads to considerable delays in the project and consequently to significant increase of the final costs [9].

NFR are considered on design stage and there are several approaches to model NFR within the scope of developed service. NFR framework [10] is a methodology that guides system to accommodate change with replaceable components. Such NFR as security, accuracy, performance and cost are used to drive the overall design process and choosing design alternatives.

KAOS [11] is another methodology, considering NFR. It allows requirements engineering, enabling analysts to build requirements models and derive requirements documents from KAOS models.

There are some other approached and methods to NRF modeling [12, 13], but all of them don't consider collaboration between FR<fnref n="8" /> and NFR. The legacy software tools, such as NFR-Assistant CASE<fnref n="9" />, ARIS<fnref n="10" />, don't provide functionality to model NRF and consider their influence on system functionality.

## 2.3 BPMN to BPEL transformation strategies

There are various BPMN to BPEL transformation strategies, such as Element-Preservation, Element-Minimization, Structure-Maximization and Structure-Identification [14], Event-Condition-Action-Rules [15] and others. A basic idea of mapping which is used in most algorithms of translating BPMN or any other WF-net into BPEL code uses a mix of mentioned strategies.

Two categories of tools are applied in practice:

1. BPMN graph is serialized to an XML document. Then the last one is automatically translated into an abstract BPEL document. The abstract BPEL is enriched with the pieces of information, necessary to make it executable.

2. BPMN graph is translated directly into executable BPEL code. This is only possible when input/output files of the future Web Service (WSDL files) are created in advance.

<footnote n="8">⁸ Functional requirements</footnote>

<footnote n="9">⁹ Quan Tran "NFR-Assistant: tool support for achieving quality", Application-Specific Systems and Software Engineering and Technology, 1999. ASSET '99. Proceedings. 1999 IEEE Symposium.</footnote>

<footnote n="10">¹⁰ http://www.softwareag.com/corporate/products/aris</footnote>
There are three main problems of BPMN-BPEL translation:

- fundamental mismatch between these two languages: BPMN is graph-structured notation while BPEL is block-structured language;

- readability of the resulting BPEL code is very low;

- translation of extended notations with additional workflow parameters, is not possible.

Hence, development of the method providing automated translation of extended BPMN elements is an important aspect in service development process.

# 3 Advanced approach to service development

Proposed advanced approach to future service development includes:

1. novel computational independent workflow design method, focusing on the work-flow model and its analysis, allowing to automate service planning stages;

2. NFR balancing method, focusing on collaboration between functional and non-functional requirements, allowing to automate service planning stages;

3. modified service workflows transformation method, providing abstract to execu-tion workflows transformation, considering workflows required parameters.

Each of the proposed methods is briefly described below.

## 3.1 Workflow design method

Workflow design includes workflow modeling and simulation. The novel method of workflow design presented in this section is focused on computational independent workflow and consists of the following stages:

- extended modeling of computational independent workflow;

- computational independent workflow analysis, including:

- forming workflow graph and verifying its connectivity;

- workflow execution time minimization;

- transformation of workflow to realization diagram.

The suggested method modifies MDA<fnref n="11" /> on the business logic level [6].

### Workflow model.

The workflow model is one of the core aspects of the proposed method, allowing its formal description and thus its in-depth analysis and transformation to more fine-grained representations. In the following the workflow formalization variant used within our approach is presented.

The mathematical formalization of a workflow can be done by using:

<footnote n="11">¹¹ Model Driven Architecture</footnote>
$$ BP = (E, I, P) \qquad (1) $$

where E is the set of workflow identification objects; I is the set of workflow informational objects and P is the set of workflow parameters of service provisioning.

The identification objects {$E_{id, id=1,4}$} include: $E_1$ = name, $E_2$ = description, $E_3$ = executor, $E_4$ = O – set of works.

The set of workflow informational objects includes income and outcome document and data objects:

$$ I = \{I_{\text{doc}}^{\text{in}}\} U \{I_{\text{dat}}^{\text{in}}\} U \{I_{\text{doc}}^{\text{out}}\} U \{I_{\text{dat}}^{\text{out}}\} \qquad (2) $$

The workflow parameters {$P_{i, i=1,6}$} cover: $P_1$ = $T_{ex}$ – execution time; $P_2$ = R – resource, required for execution; $P_3$ = A – ability to be automatically executed; $P_4$ = S – set of subsystems, used for workflow execution; $P_5$ = $F^S$ – set of separate subsystem functions, realizing task execution; $P_6$ = $P_{ad}$ – set of additional workflow parameters.

Separate work models can be represented in a formal manner as:

$$ O = (O, I^O, P) \qquad (3) $$

where O is the set of identification objects; $I^O$ is the set of informational objects; P is the set of service provision parameters.

Identification objects {$O_{id, id=1,3}$} include: $O_1$ = $N_o$ – name; $O_2$ = d – description; $O_3$ = E – executor. Task informational objects include income and outcome informational objects (document and data). Set of work parameters {$P_{i, i=1,7}^O$} include: $P_1^O$ = $\xi_{kl}$ ($r_{kl}$) – execution time of work l of stage k; $P_2^O$ = $r_{kl}$ – resource, required for execution work l of stage k; $P_3^O$ = a – the ability to be automatically executed; $P_4^O$ = S – set of OSS/BSS<fnref n="12" /> subsystems, used for workflow execution; $P_5^O$ = $F^S$ – set of OSS/BSS subsystem functions, realizing works execution; $P_6^O$ = $R_O^n$ – work realization alternatives, defining execution time and resource values:

$$ R_O^n = (N_R, \xi_{kl}^n(r_{kl}), r_{kl}^n) \qquad (4) $$

$P_7^O$ = $P_{ad}$ – set of additional work parameters.

The proposed model allows to perform workflow analysis at a planning stage, applying graph theory and optimization algorithm, represented below.

## Workflow analysis.

The workflow analysis method, providing workflow model verification, execution time minimization and automating its transformation, is briefly described below.

The workflow graph model can be represented as sequential stages, containing a few parallel executed tasks, enabling the definition of execution time as follows:

$$ T_{ex} = \sum_k \max_l \xi_{kl}^n(r_{kl}) \qquad (5) $$

The suggested method of workflow analysis is represented mathematically as:

<footnote n="12">¹² Operation Support System/Business Support System</footnote>
$$M = (G_f, G_v, M_{\min}, M_{\text{tr}}) \qquad (6)$$

where $G_f$ is the graph generating procedure; $G_v$ is the graph connectivity verification; $M_{\min}$ is the execution time minimization and $M_{\text{tr}}$ is the diagram representing the model to realization transformation. Each of the procedure is described in details in [6].

Each work of the workflow has one to three implementation variants, defining execution time and resources, the task is to find such implementation variant for each task to minimize the total workflow execution time, when the total resource is limited and known. The objective function of the task is represented below:

$$F(r) = \min_{\sum_{kl} r_{kl} = r} M \sum_{k} \max_{l} \xi_{kl}(r_{kl}) \qquad (7)$$

It is also necessary to find the implementation variant for each task, i.e. $\{r_{kl}, k = 1, ..., n, l = 1, ..., m\}$, where the required minimum of time (7) is reached. Finding the function (7), applying dynamic programming, is described in [6].

## 3.2 NFR balancing method

The proposed NFR balancing method is based on creating FR and NFR collaboration model. Implementation of functional requirements is presented by listed FB<fnref n="13" />. Each of FB is responsible for particular logical function. The proposed method includes NFR Catalogue development, FR decomposition, NFR mapping, FB distribution and Balancing stages. NFR balancing method uses NFR Catalogue and FR and create collaboration model between them. The main stages of the concept are described [16] and briefly represented below.

Catalogue of NFR. It is proposed to operate with catalogues for performance and serviceability. Catalogues are updated with further operationalizations to keep own NFR catalogues updated, which facilitates reuse of acquired knowledge on NFR.

FR decomposition. It describes influence of services features on NFR. Services and features are depicted for each FB (Table 1).

<table><caption>**Table 1.** FR decomposition</caption><thead><tr><td>Service</td><td>Functional Block</td><td>Functional Requirement</td></tr></thead><tbody><tr><td>Service1</td><td>FB1.1 or FB1.2</td><td>FR1, FR2</td></tr><tr><td>Service1</td><td>FB2.1 and FB2.2</td><td>FR3, FR1</td></tr><tr><td>Service2</td><td>FB1.1</td><td>FR5, FR6</td></tr><tr><td>Service2</td><td>FB3</td><td>FR1, FR7</td></tr></tbody></table>

NFR mapping. Each call of FB requests a defined amount of system resources (memory, processor time, etc.) and has list of characteristics: response time, availability, etc. These characteristics are mapped to NFR from catalogue with values, specifying how exact FB meets particular NFR (it is graded from 0 to 100, Table 2). One FB

<footnote n="13">¹³ Functional block</footnote>
can provide the same functionality with different NFR (FB1.1, FB1.2). From functional point of view there is no difference between these two blocks. The difference is how each FB meets the NFR. NFR mapping requires considering every service and connecting it to required FB, covering requested functionality.

<table><caption>**Table 2.** NFR mapping</caption><thead><tr><td>Functional block/ NFR</td><td>Availability</td><td>Performance</td><td>Security</td></tr></thead><tbody><tr><td>FB1.1</td><td>90</td><td>80</td><td>10</td></tr><tr><td>FB1.2</td><td>80</td><td>70</td><td>20</td></tr><tr><td>FB2.1</td><td>50</td><td>10</td><td>10</td></tr><tr><td>FB2.2</td><td>5</td><td>20</td><td>30</td></tr></tbody></table>

FB distribution. Using NFR catalogues and FR decomposition, FB distribution can be realized. Fig.1 shows that FR 1 and FR 2 from Table 1 can be implemented either by FB1.1 or FB1.2. The implementation way depends on NFR specification for particular case.

Balancing and target models. The target model is obtained by using balancing between NFR and approaches to implementation of a particular functionality with FB. For instance, there is the Customer's demand for service supporting the highest availability and there is no specified requirement for security and performance. Such case can be realized by the model, represented on Fig.2. A priority is assigned to the requirements, considered during target model development.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Functional blocks distribution</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Target deployment model</figcaption></figure>

### 3.3 Modified service workflows transformation method

The modified method is based on BPD2BPEL translation algorithm [17] which can translate arbitrary diagrams into BPEL code. BPMN extension (BPNE) [5] has been taken as an input extended business process diagram.

Key feature of proposed method is modified analysis process. When the element is analyzed, its additional parameters are also checked. If new parameters are found, information about them is saved for their subsequent transformation into BPEL elements. Proposed method considers each BPNE element.
# 4 Service design tool

BPMA. The proposed workflow design method is implemented in a new developed tool BPMA<sup>14</sup> (fig.3). It uses standard GTK+, Dia diagram editor, PyDia interface, Python Interpreter, PyGTK<sup>15</sup> and developed module BPEA, implementing workflow modeling and analysis algorithms. Main BPMA components functions are described further. “Init” realizes Dia and user intercommunication and launches modules functions. “Props” provides setting, changing and saving of workflows and its objects parameters. “Bplyzer” implements time minimization algorithms. “Transform” implements the transformation logic to create a realization diagram from workflow requirements. “Reports” generates reports on workflow modeling and analysis.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** BPMA functioning scheme.</figcaption></figure>

BPNE-BPEL transformation tool implements presented BPNE-BPEL transformation method (fig.4) [18].

<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Structural scheme of the BPNE-BPEL transformation tool</figcaption></figure>

<footnote n="14">14 Business Process Modeling & Analysis</footnote>

<footnote n="15">15 Set of Python wrappers for the GTK+ GUI library</footnote>
The tool performs transformation of data, extracted from BPNE file, into representation form, convenient for the subsequent work; translation of BPNE elements into BPEL code, using its object-oriented model; gathering all translated elements and components in a single BPEL file.

## 4.1 Case-study

Workflow design. BPMA has been tested during the planning and design of several services, such as «Bonus program», «Selling Electronic Voucher», «Tariff Plan Change» [6], in the SITRONICS Telecom Solutions company. Testing results have shown that for services, having 1-1.5 months of development time, it can be reduced by 3-5 days and development costs can be decreased by 5-7 man-days for one service; the proposed workflow analysis can reduce the time used for service provision up to 20 seconds for the services, provided in 3-5 minutes by finding the combination of tasks implementation variants, having the same resource limit.

NFR balancing. Evaluation of the proposed NFR balancing method is demonstrated on charging of GPRS service. Its FR decomposition is shown in Table 3. GPRS service availability and service delay are taken as main NFRs. Considering statistical data and enterprise knowledgebase, GPRS service characteristics were estimated (Table 4) and the GPRS service target model (fig.5) was got. The target model provides service optimal deployment configuration, ensuring service highest availability with minimal delay. The proposed method is experimentally proved to be efficient when services design and deployment, providing NFR modeling, providing service functionality with required functional and non-functional parameters.

<table><caption>**Table 3.** FR decomposition of GPRS service</caption><thead><tr><td>Service</td><td>Functional Block</td><td>Functional Requirement</td></tr></thead><tbody><tr><td>GPRS</td><td>LBS1.1 or LBS1.2</td><td>Location Base Charging</td></tr><tr><td>GPRS</td><td>RF2.1 and RF2.2</td><td>Step Charging</td></tr><tr><td>GPRS</td><td>NB3.1 or NB 3.2 or NB3.3.</td><td>User notification</td></tr></tbody></table>

<table><caption>**Table 4.** NFR mapping of GPRS service</caption><thead><tr><td>Functional block/ NFR</td><td>Availability</td><td>Delay</td></tr></thead><tbody><tr><td>LBS1.1- location based module implemented as internal cache in Online Charging System</td><td>90</td><td>80</td></tr><tr><td>LBS1.2-external Home Zone Billing -HZB platform</td><td>50</td><td>10</td></tr><tr><td>RF2.1- internal Rating</td><td>50</td><td>20</td></tr><tr><td>RF2.2- external Rating</td><td>5</td><td>15</td></tr><tr><td>NB3.1- notification via SMS</td><td>40</td><td>50</td></tr><tr><td>NB3.2-online notification via USSD</td><td>50</td><td>40</td></tr><tr><td>NB3.3- offline notification via email</td><td>50</td><td>10</td></tr></tbody></table>
<figure><img src="image_6.png" /><figcaption>Fig. 5. Target model for GPRS service</figcaption></figure>

# 5 Summary and outlook

A novel approach for analyzing and developing modern services, provided by web-oriented applications, has been proposed. The discussion is focused on the development of a computational independent workflow model, its analysis, transformation of abstract into executional workflows, and also aspect of NFR balancing when service development. The proposed workflow model provides formalization of service provision parameters, required for the planning stage. The analysis methods allow automating service planning and minimizing service provision time. The workflow design method reduces the time of system adaptation up to 10% by improving and automating the service planning stage.

The proposed NFR balancing method provides NFR description, considering collaboration between services and meeting NFR by system FB. The method increases efficiency of service development on design and deployment stages and allows fast system reconfiguration on customer demand.

Modified BPMN-BPEL transformation method and tool provides automation of abstract workflows transformation into execution ones, allowing to consider workflow required parameters.

Future work will focus on analysis of computing workflows and their enactment, services monitoring and re-configuration, which are strongly connected to the design and analysis stages. NFR balancing method will be extended with possibility to consider possible change of NFR list and their priorities during different time period (e.g. periods with high load) and also take into account changing priority between services.

Key aspects of the proposed approach to future service development can be applied to extend ISO/IEC/IEEE 29148:2011 Standard, dealing with the processes and products related to the engineering of requirements for systems and software products and services throughout the life cycle, to raise the overall efficiency of service development and re-engineering.

# References

1. Kornel Terplan. OSS Essentials: Support System Solutions for Service Providers / Kornel Terplan. - New York : John Wiley, 2001. – 610 pages.

2. RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers: http://tools.ietf.org/html/rfc2474
3. J. Recker, J. Mendling: "On the Translation between BPMN and BPEL: Conceptual Mis-match between Process Modeling Languages." CAiSE 2006 Workshop Proceedings - Eleventh International Workshop on EMMSAD, June 5 - 6, 2006, Luxembourg, pp. 521-532.

4. Börger E. Approaches to modeling business processes: a critical analysis of BPMN, workflow patterns and YAWL. Software and system modeling, vol.11, number 3, pp. 305-318. Springer (2011)..

5. Kot T., Globa L., Schill A. Applying business process modeling method when telecommu-nication services development. // Proceedings of International Conference on Microwave and Telecommunication Technology (CriMiCo), 2011. – Sevastopol. - Vol.1. - P. 457 – 458.

6. Kot T., Reverchuk A., Globa L., Schill A. A novel approach to increase efficiency of OSS/BSS workflow planning and design. Lecture Notes in Business Information Pro-cessing, vol.117, pp. 142-152. Springer (2012).

7. Ian J. Taylor. Workflows for e-Science Scientific Workflows for Grids / Ian J. Taylor, Ewa Deelman, Dennis B. Gannon, Matthew Shields. Scientific Workflows for Grids, 523 p. Springer (2007).

8. W. van der Aalst. BPM and Workflow Analysis. BPTrends, 5(4): 1-2, April 2007.

9. Software Errors Cost U.S. Economy $59.5 Billion Annually. NIST Assesses Technical Needs of Industry to Improve Software-Testing. - 2002. - http://www.cse.buffalo.edu/~mikeb/Billions.pdf

10. Chung L., Nixon B. A., Yu E. and Mylopoulos J. Non-Functional Requirements in Soft-ware Engineering. – Boston: Kluwer Academic Publishers, 2000. - 472 p.

11. A KAOS Tutorial - 2007 - http://wwwobjectiver.com/fileadmin/download/documents/KaosTutorial.pdf

12. Yu E., Giorgini P., Maiden N., Mylopoulos J. Social Modeling for Requirements Engi-neering. - Cambridge, MA: MIT Press, 2011. – 752 p.

13. Axel van Lamsweerde. Requirements Engineering: From System Goals to UML Models to Software Specifications. - John Wiley and Sons, 2009. - 650 p.

14. J. Mendling, K. Lassen, U. Zdun: "Transformation Strategies between Block-Oriented and Graph-Oriented Process Modelling Languages." MKWI 2006, Band 2, XML4BPM Track, GITO-Verlag Berlin, 2006, ISBN 3-936771-62-6, pp. 297-312.

15. Mendling J., Lassen K., Zdun U. On the Transformation of Control Flow between Block-Oriented and Graph-Oriented Process Modeling Languages // IJBPIM. Special Issue on Model-Driven Engineering of Executable Business Process Models. -2008. - Vol. 3, N. 2, - P. 96-108.

16. Kot, T., Reverchuk, A., Globa, L., Schill, A. Method of non-functional requirements bal-ancing when service development. // Proceedings of the International Multi-Conference ACS-AISBIS'2012, May-June, 2012. – Szczecin: Journal of Theoretical and Applied Computer Science. -2012. - Vol. 6, N. 3. - P. 50-57.

17. Ouyang C. From Business Process Models to Process-Oriented Software Systems / C. Ouyang, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, J. Mendling // ACM Transactions on Software Engineering and Methodology — 2009 — Vol.19 — P. 1-37.

18. D. Pukhkaiev, T. Kot, L. Globa Translating BPMN/BPNE into BPEL // 11-th International Conference «TCSET’2012». Conference Proceedings. — Lviv-Slavske, Ukraine — 2012 — Vol.1 — P. 386.