Software Engineering Techniques - CEE-SET 2008

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen TU Dortmund University, Germany Madhu Sudan Microsoft Research, Cambridge, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max Planck Institute for Informatics, Saarbruecken, Germany

4980

Zbigniew Huzar Radek Koci Bertrand Meyer Bartosz Walter Jaroslav Zendulka (Eds.)

Software Engineering Techniques Conference Third IFIP TC 2 Central and East European CEE-SET 2008 Brno, Czech Republic, October 13-15, 2008 Revised Selected Papers

13

Volume Editors Zbigniew Huzar Wrocław University of Technology Wybrze˙ze Wyspia´nskiego 27, 50-370 Wrocław, Poland E-mail: [email protected] Radek Koci Jaroslav Zendulka Brno University of Technology Božetˇechova 2, 612 66 Brno, Czech Republic E-mail: {koci, zendulka}@fit.vutbr.cz Bertrand Meyer ETH Zurich Clausiusstr. 59, 8092 Zurich Switzerland E-mail: [email protected] Bartosz Walter Pozna´n University of Technology Piotrowo 2, 60-965 Pozna´n, Poland E-mail: [email protected]

ISSN 0302-9743 e-ISSN 1611-3349 ISBN 978-3-642-22385-3 e-ISBN 978-3-642-22386-0 DOI 10.1007/978-3-642-22386-0 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011930847 CR Subject Classification (1998): D.2, K.6.3, K.6, K.4.3, D.3, F.3.2, J.1 LNCS Sublibrary: SL 2 – Programming and Software Engineering

© IFIP International Federation for Information Processing 2011 the material is This work is subject to copyright. All rights are reserved, whether the whole or part of broadcasting, concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, this publication reproduction on microfilms or in any other way, and storage in data banks. Duplication of 9, 1965, or parts thereof is permitted only under the provisions of the German Copyright Law of Septemberare liable in its current version, and permission for use must always be obtained from Springer. Violations to prosecution under the German Copyright Law. does not imply, The use of general descriptive names, registered names, trademarks, etc. in this publication protective laws even in the absence of a specific statement, that such names are exempt from the relevant and regulations and therefore free for general use. India Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

The predecessor of CEE-SET was the Polish Conference on Software Engineering, KKIO, organized annually since 1999. In 2006 KKIO changed to an international conference on Software Engineering Techniques SET 2006 sponsored by Technical Committee 2 (Software: Theory and Practice) of the International Federation for Information Processing, IFIP [http://www.ifip.org/]. In 2007 the conference got a new name: IFIP TC2 Central and East-European Conference on Software Engineering Techniques, CEE-SET. In 2008 the conference took place in Brno, Czech Republic, and lasted for three days, October 13–15, 2008 (the details are on the conference website http://www.cee-set.put.poznan.pl/2008/). The conference aim was to bring together software engineering researchers and practitioners, mainly from Central and East-European countries (but not only), and to allow them to share their ideas and experiences. The conference was technically sponsored by: – – – – – – – –

IFIP Technical Committee 2, Software: Theory and Practice Czech Society for Cybernetics and Informatics (CSKI) Gesellschaft f¨ ur Informatik, Special Interest Group Software Engineering John von Neumann Computer Society (NJSZT), Hungary Lithuanian Computer Society Polish Academy of Sciences, Committee for Informatics Polish Information Processing Society Slovak Society for Computer Science

The financial support was provided by Visegrad Fund, CSKI, and Brno University of Technology. The conference program consisted of three keynote speeches given by Krzysztof Czarnecki (University of Waterloo, Canada), Thomas Gschwind (IBM Zurich Research Lab, Switzerland), and Mauro Pezz (University of Milano Bicocca, Italy), 21 regular presentations selected from 69 submissions (success rate was about 30%), and 20 work-in-progress presentations. The International Program Committee decided that the Best Paper Award would be presented to: L  ukasz Olek, Jerzy Nawrocki and Miroslaw Ochodek for the paper “Enhancing Use Cases with Screen Designs.” This volume contains a keynote speech by Thomas Gschwind and regular presentations given at the conference. We believe that publishing these high-quality papers will support a wider discussion on software engineering techniques. Zbigniew Huzar Radek Koci Bertrand Meyer Bartosz Walter Jaroslav Zendulka

Organization

Program Committee Pekka Abrahamsson Vincenzo Ambriola Nathan Baddoo Vladim´ır Bart´ık Hubert Baumeister Maria Bielikova M. Biro Pere Botella Albertas Caplinskas Gabor Fazekas K. Geihs Janusz Gorski Bogumila Hnatkowska Petr Hnetynka Tomas Hruska Zbigniew Huzar Paul Klint Jan Kollar Laszlo Kozma Leszek Maciaszek Jan Madey Lech Madeyski Zygmunt Mazur Bertrand Meyer Matthias M¨ uller J¨ urgen M¨ unch Jerzy Nawrocki Miroslav Ochodek L  ukasz Olek

VTT Technical Research Centre of Finland University of Pisa, Italy University of Hertfordshire, UK Brno University of Technology, Czech Republic Technical University of Denmark Slovak University of Technology in Bratislava, Slovakia John von Neumann Computer Society and Corvinus University of Budapest, Hungary Universitat Politecnica de Catalunya, Spain Institute of Mathematics and Informatics Lithuania University of Debrecen, Hungary Universit¨ at Kassel, Germany Gdansk University of Technology, FETI, DSE, Poland Institute of Applied Informatics, Wroclaw University of Technology, Poland Charles University in Prague, Czech Republic Brno University of Technology, Czech Republic Wroclaw University of Technology, Poland Centrum voor Wiskunde en Informatica, The Netherlands Technical University Kosice, Slovakia E¨otv¨ os Lor´ and University, Hungary Macquarie University Sydney, Australia Warsaw University, Poland Wroclaw University of Technology, Poland Wroclaw Institute of Technology, Poland ETH Zurich, Switzerland IDOS Software AG, Germany Fraunhofer Institute for Experimental Software Engineering, Germany Pozna´ n University of Technology, Poland Pozna´ n University of Technology, Poland Pozna´ n University of Technology, Poland

VIII

Organization

Janis Osis Erhard Ploedereder Saulius Ragaisis Felix Redmill Marek Rychl´ y Krzysztof Sacha Wilhelm Schaefer Giancarlo Succi Tomasz Szmuc Marcin Szpyrka Andrey Terekhov Richard Torkar Corrado Aaron Visaggio Tomas Vojnar Bartosz Walter Jaroslav Zendulka Krzysztof Zielinski

Riga Technical University, Latvia University of Stuttgart, Germany Vilnius University, Lithuania Newcastle University, UK Brno University of Technology, Czech Republic Warsaw University of Technology, Poland University of Paderborn, Germany Free University of Bolzano-Bozen, Italy AGH University of Science and Technology, Poland AGH University of Science and Technology, Poland St. Petersburg State University, Russia Blekinge Institute of Technology, Sweden University of Sannio, Italy Brno University of Technology, Czech Republic Pozna´ n University of Technology, Poland Brno University of Technology, Czech Republic AGH University of Science and Technology, Poland

Additional Reviewers Adamek, Jiri Bleul, Steffen Fryzlewicz, Zbigniew Gall, Dariusz Habermehl, Peter Henkler, Stefan Hirsch, Martin Holik, Lukas Khan, Mohammad Ullah Krena, Bohuslav

Letko, Zdenek Michalik, Bartosz Ochodek, Miroslaw Parizek, Pavel Reichle, Roland Skubch, Hendrik Sudmann, Oliver von Detten, Markus Vranic, Valentino

Table of Contents

Keynote Towards a Compiler for Business-IT Systems: A Vision Statement Complemented with a Research Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jana Koehler, Thomas Gschwind, Jochen K¨ uster, Hagen V¨ olzer, and Olaf Zimmermann

1

Requirements Specification Towards Use-Cases Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bartosz Alchimowicz, Jakub Jurkiewicz, Jerzy Nawrocki, and Miroslaw Ochodek

20

Automated Generation of Implementation from Textual System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jan Franc˚ u and Petr Hnˇetynka

34

Enhancing Use Cases with Screen Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . L  ukasz Olek, Jerzy Nawrocki, and Miroslaw Ochodek

48

Design Mining Design Patterns from Existing Projects Using Static and Run-Time Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Michal Dobiˇs and L’ubom´ır Majt´ as

62

Transformational Design of Business Processes for SOA . . . . . . . . . . . . . . . Andrzej Ratkowski and Andrzej Zalewski

76

Service-Based Realization of Business Processes Driven by Control-Flow Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Petr Weiss

91

Modeling SMA—The Smyle Modeling Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benedikt Bollig, Joost-Pieter Katoen, Carsten Kern, and Martin Leucker

103

X

Table of Contents

Open Work of Two-Hemisphere Model Transformation Definition into UML Class Diagram in the Context of MDA . . . . . . . . . . . . . . . . . . . . . . . . Oksana Nikiforova and Natalja Pavlova

118

HTCPNs–Based Tool for Web–Server Clusters Development . . . . . . . . . . . Slawomir Samolej and Tomasz Szmuc

131

Software Product Lines Software Product Line Adoption – Guidelines from a Case Study . . . . . . Pasi Kuvaja, Jouni Simil¨ a, and Hanna Hanhela

143

Refactoring the Documentation of Software Product Lines . . . . . . . . . . . . Konstantin Romanovsky, Dmitry Koznov, and Leonid Minchin

158

Code Generation Code Generation for a Bi-dimensional Composition Mechanism . . . . . . . . Jacky Estublier, Anca Daniela Ionita, and Tam Nguyen

171

Advanced Data Organization for Java-Powered Mobile Devices . . . . . . . . ˇ Tom´ aˇs Tureˇcek and Petr Saloun

186

Developing Applications with Aspect-Oriented Change Realization . . . . . Valentino Vrani´c, Michal Bebjak, Radoslav Menkyna, and Peter Dolog

192

Project Management Assessing the Quality of Quality Gate Reference Processes . . . . . . . . . . . . Thomas Flohr

207

Exploratory Comparison of Expert and Novice Pair Programmers . . . . . . Andreas H¨ ofer

218

State of the Practice in Software Effort Estimation: A Survey and Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adam Trendowicz, J¨ urgen M¨ unch, and Ross Jeffery

232

Quality Testing of Heuristic Methods: A Case Study of Greedy Algorithm . . . . . . A.C. Barus, T.Y. Chen, D. Grant, Fei-Ching Kuo, and M.F. Lau

246

Table of Contents

XI

A Framework for Defect Prediction in Specific Software Project Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dindin Wahyudin, Rudolf Ramler, and Stefan Biffl

261

Meeting Organisational Needs and Quality Assurance through Balancing Agile and Formal Usability Testing Results . . . . . . . . . . . . . . . . Jeff Winter, Kari R¨ onkk¨ o, M˚ arten Ahlberg, and Jo Hotchkiss

275

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

291

Towards a Compiler for Business-IT Systems A Vision Statement Complemented with a Research Agenda Jana Koehler, Thomas Gschwind, Jochen K¨uster, Hagen V¨olzer, and Olaf Zimmermann IBM Zurich Resarch Laboratory S¨aumerstrasse 4, CH-8038 R¨uschlikon, Switzerland

Abstract. Business information systems and enterprise applications have continuously evolved into Business-IT systems over the last decades, directly linking and integrating Business Process Management with recent technology evolutions such as Web services and Service-Oriented Architectures. Many of these technological evolutions include areas of past academic research: Business rules closely relate to expert systems, Semantic Web technology uses results from description logics, attempts have been made to compose Web services using intelligent planning techniques, and the analysis of business processes and Web service choreographies often relies on model checking. As such, many of the problems that arise with these new technologies have been solved at least in principle. However, if we try to apply these “in principle” solutions, we are confronted with the failure of these solutions in practice: many proposed solution techniques do not scale to the real-world requirements or they rely on assumptions that are not satisfied by Business-IT systems. As has been observed previously, research in this area is fragmented and does not follow a truly interdisciplinary approach. To overcome this fragmentation, we propose the vision of a compiler for Business-IT systems that takes business process specifications described at various degrees of detail as input and compiles them into executable IT systems. As any classical compiler, the parsing, analysis, optimization, code generation and linking phases are supported. We describe a set of ten research problems that we see as critical to bring our compiler vision to reality.

1 Introduction Business processes comprise sequences of activities that bring people, IT systems, and other machines together to act on information and raw materials. They allow a business to produce goods and services and deliver them to its customers. A business is a collection of business processes and thus (re-)engineering business processes to be efficient is one of the primary functions of a company’s management. This is one of the most fundamental mechanisms that drives advances in our society. Business Process Management (BPM) is a structured way to manage the life cycle of business processes including their modeling (analysis and design), execution, monitoring, and optimization. Good tools exist that allow business processes to be analyzed and designed in an iterative process. Creating a model for a process provides insights that Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 1–19, 2011. c IFIP International Federation for Information Processing 2011 

2

J. Koehler et al.

allow the design of a process to be improved, in particular if the modeling tool supports process simulation. A Service-Oriented Architecture (SOA), which is often implemented using Web services, is an architectural style that allows IT systems to be integrated in a standard way, which lends itself to the efficient implementation of business processes. SOA also enables efficient process re-engineering as the use of standard programming models and interfaces makes it much simpler to change the way in which the components of business processes are integrated. Once a process is implemented, it can be monitored, e.g., measured, and then further optimized to improve the quality, the performance, or some other aspect of the process. Despite the progress that has been made recently in business process design and modeling on the one hand, and their execution and monitoring on the other, there is a significant gap in the overall BPM life cycle, which severely limits the ability of companies to realize the benefits of BPM. No complete solution exists to automate the translation from business process models to executable business processes. While partial solutions exist that allow some process models to be mapped to implementations (workflows), scalable and automated approaches do not exist that would support businesses in the full exploitation of the BPM life cycle to achieve rapid improvements of their business processes. Thus, many of the benefits of process modeling and SOA cannot be realized and effective BPM remains a vision. As has been observed previously, research in this area is fragmented and does not follow a truly interdisciplinary approach. This lack of interdisciplinary research is seen as a major impediment that limits added economic growth through deployment and use of services technology [1]: The subject of SOC1 is vast and enormously complex, spanning many concepts and technologies that find their origins in diverse disciplines that are woven together in an intricate manner. In addition, there is a need to merge technology with an understanding of business processes and organizational structures, a combination of recognizing an enterprise’s pain points and the potential solutions that can be applied to correct them. The material in research spans an immense and diverse spectrum of literature, in origin and in character. As a result research activities at both worldwide as well as at European level are very fragmented. This necessitates that a broader vision and perspective be established one that permeates and transforms the fundamental requirements of complex applications that require the use of the SOC paradigm. This paper presents a concrete technological vision and foundation to overcome the fragmentation of research in the BPM/SOA area. We propose the vision of a compiler for Business-IT systems that takes business process specifications described at various degrees of detail as input and compiles them into executable IT systems. This may sound rather adventurous, however, recall how the first compiler pioneers were questioned when they suggested to programmers that they should move from hand-written 1

SOC stands for Service-Oriented Computing a term that is also used to denote research in the area of BPM and SOA. The still evolving terminology is a further indicator of the emerging nature of this new research field.

Towards a Compiler for Business-IT Systems

3

assembly code to abstract programming languages from which machine-generated code would then be produced. The emerging new process-oriented programming languages such as the Business Process Execution Language (BPEL) [2] or the Business Process Modeling Notation (BPMN) [3] are examples of languages that are input to such a compiler. In particular, the upcoming version 2 of the Business Process Modeling Notation (BPMN) [3] can be considered as a language that at the same time allows non-technical users to describe business processes in a graphical notation, while technical users can enrich these descriptions textually until the implementation of the business process is completely specified. With its formally defined execution semantics, BPMN 2.0 is directly executable. However, direct execution in the literal meaning of the words means to follow an interpreter-based approach with all its shortcomings, which cannot be considered as really desirable. The envisioned compiler does not take a high-level business process model, magically adds all the missing information pieces, and then compiles it into executable code. The need to go from an analysis model to a design model in an iterative refinement process that involves human experts does not disappear. The compiler enables human experts to more easily check and validate their process model programs. The validation helps them in determining the sources of errors as well as the information that is missing. Only once all the required information is available, the code can be completely generated. The compiler approach also extends the Model-Driven Architecture (MDA) vision; beyond model transformations that provide a mapping between models with different abstractions, we combine code generation with powerful analytical techniques. Static analysis is performed yielding detailed diagnostic information and structural representations similar to the abstract syntax tree are used by the Business-IT systems compiler. This provides a more complete understanding of the process models, which is the basis for error handling, correct translation, and runtime execution. The paper is organized as follows: In Section 2, we motivate the need for a BusinessIT systems compiler by looking at BPM life cycle challenges. In Section 3, we summarize the ten research problems that we consider as particularly interesting and important to solve. In Section 4, we discuss the problems in more detail and review selected related work. Section 5 concludes the paper.

2 Life Cycle Challenges in Business-IT Systems The IT Infrastructure underlying a business is a critical success factor. Even when IT is positioned as a commodity such as by Nicolas Carr in “IT doesn’t matter,” it is emphasized that a disruptive new technology has arrived, which requires companies to master the economic forces that the new technology is unleashing. In particular smaller companies are not so well positioned in this situation. The new technology in the form of Business Process Management (BPM) and Service-Oriented Architecture (SOA) is complex to use, still undergoing significant changes, and it is difficult even for the expert to distinguish hype from mature technology development. There is wide agreement that business processes are the central focus area of the new technology wave. On the one hand, business processes are undergoing dramatic change made possible by the technology. On the other hand, increasing needs in making business processes more flexible, while retaining their integrity and compliance with legal

4

J. Koehler et al.

Standardize & Establish new regulations

Industry Standard

Standardized Reuse & Configure Process

Adopt regulation solutions

Best Practice Industry Asset

Configured

Reference

Best Practice

Process

Process

Harvest As-Is Process As-Is Analysis Model

To-Be Process To-Be Analysis Model

abstract As-Is Design Model

deploy Runtime

Add innovative business model elements

refine

IT Architectural BusinessDecision Driven + Making Development

To-Be Design Model

Fig. 1. Driving Forces behind the Life Cycle of Business Processes

regulations continue to drive technology advances in this space. A prominent failure in process integrity is the financial crisis that emerged throughout 2008. Figure 1 reflects our current view of the driving forces behind the life cycle of business processes. Two interleaved trends of commoditization and innovation have to be mastered that involve the solution of many technical problems. Let us spend some space discussing this picture to explain why this is a challenge for most businesses today and why underpinning business process innovation with compiler technology is essential to master the innovation challenge. Let us begin in the lower left corner with the As-Is Process box. This box describes the present situation of a business. Any business has many processes implemented, many of them run today in an IT-supported environment. As such they were derived from some As-Is design model and deployed. Sometimes, the design model is simply the code. The As-Is design model is linked to an As-Is analysis model. Here, we adopt the terminology from software modeling that distinguishes between an analysis model (in our case, the business view on the processes) and the design model (in our case, the implemented processes). The analysis model is usually an abstraction from the design model, i.e., a common view of the business on the implemented processes exists in many companies.2 The direct linkage between the business view on the processes and their implementation constitutes the Business-IT system. 2

By monitoring or mining the running processes or analyzing and abstracting the underlying design model or code in some form, an analysis model can also be produced in an automatic or semi-automatic manner, but this is beyond the focus of this paper.

Towards a Compiler for Business-IT Systems

5

The As-Is processes implemented by the players in an industry represent the state of the art of the Business-IT systems. Industries tend to develop a solid understanding of good and bad practices and often develop best practice reference solutions. Very often, consulting firms also specialize in helping businesses understanding and adopting these best practice processes. Today, one can even see a trend beyond adoption. For example, in the financial industry one can see first trends towards standardized processes that are closely linked to new regulations. This clearly creates a trend of commoditization forcing companies to adopt the new regulation solutions. With that we have arrived at the upper right corner of the picture. The commoditization trend is pervasive in the economic model of the western society and it is as such not surprising that it now reaches into business processes. However, in a profit-driven economy, commoditization is not desirable as it erodes profit. Businesses are thus forced to escape the commoditization trap, which they mostly approach by either adopting new technologies or by inventing new business models. Both approaches directly lead to innovations in the business processes. In the picture above, the new business processes that result from the innovation trend are shown as the To-Be processes, which have to both accommodate commoditization requirements and as well as to include innovation elements at the same time. The To-Be innovation must also be evident with respect to the As-Is process and the best practice process, which is illustrated in the picture with the reference to a delta analysis involving the three process models. The To-Be process is usually (but not always) initiated at the analysis level, i.e., the business develops a need for change and begins to define this change. The ToBe analysis model must be refined into a To-Be design model and then taking through a business-driven development and IT-architectural decision process that is very complex today. With the successful completion of the development, the To-Be process becomes the new As-Is process. With that the trends of commoditization and innovation repeat within the life cycle of business processes [4,5]. This paper focuses on the technological underpinnings for business process innovation, i.e., the adoption of best practice processes, their combination with innovative elements, and the replacement of the As-Is process by the To-Be process. We investigate these challenges from a strictly technological point of view and identify a number of specific problems that are yet unsolved, but have to be solved in order to support businesses in their innovation needs. Problems of process abstraction, harvesting, and standardization are also of general interest, but are outside the scope of this vision as is a study of the economic or social effects of what has been discussed above.

3 Compilation Phases and Associated Research Problems Our main goal is to understand how a compiler for Business-IT systems works. At its core, we see the compilation of business process models that constitutes a well-defined problem. In the following, we relate the principal functionalities of a programming language compiler to the corresponding problems of compiling a business process model. Following Muchnik [6] “compilers are tools that generate efficient mappings from programs to machines”. Muchnik also points out that languages, machines, and target architectures continue to change and that the programs become ever more ambitious in their scale and complexity. In our understanding, languages such as BPMN are the

6

J. Koehler et al.

new forms of programs and SOA is a new type of architecture that we have to tackle with compilers. A compiler-oriented approach helps to solve the business problems and to address the technical challenges around BPM/SOA. For example, verifying the compliance and integrity of a business with legal requirements must rely on a formal foundation. Furthermore, agility in responding to innovation requires a higher degree of automation. At a high-level, a compiler works in the following five phases: 1. 2. 3. 4. 5.

Lexical analysis and parsing Structural and semantic analysis Translation and intermediate code generation Optimization Final assembly and linking and further optimization

We envision the compiler for Business-IT systems to work in the same five phases. While we consider the parsing and lexical analysis phase as essentially being solved by our previous and current work, we propose ten specific research problems that address key problems for the subsequent phases. The list below briefly summarizes the ten problems. In Section 4, they are discussed in more detail. 1. Lexical analysis and parsing: We developed the Process Structure Tree (PST) as a unique decomposition of the workflow graph, which underlies any business process model, into a tree of fragments that can be computed in linear time. The PST plays the same role in the Business-IT systems compiler as the Abstract Syntax Tree (AST) in a classical compiler. 2. Structural and semantic analysis: We developed a control-flow analysis for workflow graphs that exploits the PST and demonstrates its usefulness, but which can still be significantly expanded in terms of the analysis results it delivers as well as the scope of models to which it can be applied. Problem 1: Clarify the role of orchestrations and choreographies in the compiler. Process models describe the flow of tasks for one partner (orchestration) as well as the communication between several partners (choreographies). Structural and semantic analysis must be extended to choreographies and orchestration models. Furthermore, it must be clarified which role choreography specifications play during the compilation process. Problem 2: Solve the flow separation problem for arbitrary process orchestrations. Process orchestrations can contain specifications of normal as well as errorhandling flows. Both flows can be interwoven in an unstructured diagram, with their separation being a difficult, not yet well-understood problem. Problem 3: Transfer and extend data-flow analysis techniques from classical compilers to Business-IT systems compilers. Processes manipulate business data, which is captured as data flow in process models. Successful techniques such as Concurrent Single Static Assignment (CSSA) must be transferred to the Business-IT systems compiler. Problem 4: Solve the temporal projection problem for arbitrary process orchestrations. Process models are commonly annotated with information about states and events. This information is usually available at the level of a single task, but must be propagated over process fragments, which can exhibit a complex structure including cycles.

Towards a Compiler for Business-IT Systems

7

Problem 5: Develop scalable methods to verify the termination of a process choreography returning detailed diagnostic information in case of failure. Correctly specifying the interaction between partners that execute complex process orchestrations in a choreography model is a challenging modeling task for humans. In particular, determining whether the orchestration terminates is a fundamental analysis technique that the compiler must provide in a scalable manner. 3. Translation and intermediate code generation: Many attempts exist to translate business-level process languages such as BPMN to those languages used by the runtime such as BPEL. None of the proposed approaches is satisfying due to strong limitations in the subsets of the languages that can be handled and the quality of the generated code, which is often verbose. Major efforts have to be made to improve the current situation. Problem 6: Define a translation from BPMN to BPEL and precisely characterize the maximal set(s) of BPMN diagrams that are translatable to structured BPEL.3 4. Optimization: Code generated today or attempts to natively execute processoriented languages are very limited with respect to the further optimization of the code. Specific characteristics of the target IT architecture are rarely taken into account. Problem 7: Define execution optimization techniques for the Business-IT systems compiler. Until today, business processes are usually optimized with respect to their costs. No optimization of a process with respect to the desired target platform happens automatically as it is available in a classical compiler. It is an open question which optimizations should be applied when processes are compiled for a Service-Oriented Architecture. 5. Final assembly, linking and further optimization: Assembly and linking problems in a Service-Oriented Architecture immediately define problems of Web service reuse and composition, for which no satisfying solutions have been found yet. Problem 8: Redefine the Web service composition problem such that it is grounded in realistic assumptions and delivers scalable solutions. Web service composition is studied today mostly from a Semantic Web perspective assuming that rich semantic annotations are available that are provided by humans. A compiler, however, should be able to perform the composition and linking of service components without requiring such annotations. Problem 9: Redefine the adapter synthesis problem by taking into consideration constraints that occur in business scenarios. Incorrect choreographies have to be repaired. Often, this is achieved by not changing the processes that are involved in the choreography, but by synthesizing an adapter that allows the partners to successfully communicate with each other. Such an adapter often must include comprehensive protocol mediation capabilities. So far, no satisfying solutions have been found for this problem and we argue that it must be reformulated under realistic constraints. 3

We only define a single problem focusing on the challenge of BPMN-BPEL translation, although the question of an adequate BPEL-independent “byte-code” level for BPMN is also very interesting and deserves further study.

8

J. Koehler et al.

Problem 10: Demonstrate how IT architectural knowledge and decisions are used within the compiler. The target platform for the Business-IT systems compiler is a Service-Oriented Architecture. Architectural decision making is increasingly done with tools that make architectural decisions explicit and manage their consistency. These decisions can thus become part of the compilation process, making it easier to compile processes for different back end systems. The positioning of these ten problems within the various compilation phases makes it possible for researchers to tackle them systematically, study their interrelationships, and solve the problems under realistic boundary constraints. Our vision allows us to position problems in a consistent and comprehensive framework that have previously been tackled in isolation. This can lead to synergies between the various possible solution techniques and allows researchers to successfully transfer techniques that were successful in one problem space to another. Our vision provides researchers with continuity in the technological development, with compilers tackling increasingly complex languages and architectures. A solution of the ten research problems has significant impact on the integrity, improved agility and higher automation within BPM/SOA.

4 A Deeper Dive into the Research Problems A compiler significantly increases the quality of the produced solution and provides clearer traceability. Approaches of manual translation are envisioned to be replaced by tool-supported refinement steps guided by detailed diagnostic information. The optimization of Business-IT systems with respect to their execution becomes possible, which can be expected to lead to systems with greater flexibility making it easier for businesses to follow the life cycle of process innovation. A compiler can also help in automating many manual steps and be expected to produce higher-quality results than those that can be obtained by manual, unsupported refinement and implementation steps. With the compiler approach, we propose to go beyond the Model-Driven Architecture (MDA) vision that proposes models at different levels of abstraction and model transformations to go from a more abstract to a more refined model. Two problems prevent that MDA is fully workable for BPM/SOA. If used at all, model transformations are written mostly in an ad-hoc manner in industrial projects today. They rarely use powerful analytical techniques such as the static analysis performed by compilers, nor do they exploit structural representations similar to the abstract syntax tree that a compiler builds for a program. Furthermore, too many different models result from the transformations with traceability between these models remaining an unsolved problem so far. In the following, we review selected related work in the context of the five phases. The review will not be a comprehensive survey of the state of the art. We focus on where we stand in our own research with respect to the compiler for Business-IT systems and point by example to other existing work in various fields of computer science that we consider as relevant when tackling the problems that we define for the five phases.

Towards a Compiler for Business-IT Systems f1

j1

f2

a1

j2

f7

j6 a6

a5

a3

f4

a8 f3

a2

d1

a9

a7 m4

f5

j4

a14

a10 a11 d2

j3

a4

m1

d4

m3

m2

j5 a16

f6 m5

a13

a12

9

d3

a17

a15

Fig. 2. Workflow graph of an example process model in a UML Activity Diagram-like notation

4.1 Parsing The parsing problem for business process models has not yet been widely recognized by the BPM community as an important problem. Figure 2 shows a typical workflow graph underlying any business process model. It includes activities ai , decisions di , merges mi (for alternative branching and joining) as well as forks fi and joins ji (for parallel branching and joining). Today, process-oriented tools treat such models as large, unstructured graphs. No data structure such as the Abstract Syntax Tree (AST) used by compilers is available in these tools. In our own research, we developed the Process Structure Tree (PST) [7,8], which we consider to be the AST analogy for Business-IT systems compilers. The PST is a fundamental data structure for all the subsequent phases of a compilation. By applying techniques from the analysis of program structure trees [9,10,11,12] to business process models a unique decomposition of process models into a tree of fragments can be computed using a linear time algorithm. The PST is a significant improvement compared to approaches that use graph grammars to parse the visual language, which is exponential in most cases [13]. Figure 3 shows the PST for the workflow graph of Figure 2. With this, we believe that the parsing problem for the Business-IT systems compiler is solved for the near future. Additional improvements can be imagined, but in the Z f7 J d1 C

Y

K

L

a4 a5

a6

a7 a8

j6

V

D m1 f2 E F f3 G j2 H I j3 a9 d2 O m2

f1 A B j1 a3 a1 a2

X

f4 M

W

P m3 Q d3 d4 f5 R f6 S m4 T m5 U j5

N j4 a12

a13

a14

a15

a10 a11

Fig. 3. Process Structure Tree (PST) for the workflow graph of Figure 2

a16

a17

10

J. Koehler et al.

following we concentrate on the other phases of the compiler, which help validating that the PST is indeed as powerful as the AST. 4.2 Structural and Semantic Analysis In our own research, we have developed two types of analysis based on the PST: a) a control-flow analysis [7,14] and b) an approach to the structural comparison and difference analysis of process models [15]. Both demonstrated that the PST is an essential prerequisite and a powerful data structure to implement various forms of analyses. In the following, we shortly summarize our current insights into the analysis problem and identify a set of concrete problems that we consider as being especially relevant and interesting. A business process model is also often referred to as a process orchestration. A process orchestration (the control- or sequence flow) describes how a single business process is composed out of process tasks and subprocesses. In a SOA implementation, each task or subprocess is implemented as a service, where services can also be complex computations encapsulating other process orchestrations. In contrast to an orchestration, a process choreography describes the communication and thus the dependencies between several process orchestrations. Note that the distinction between orchestration and choreography is a “soft” one and usually depends on the point of view of the modeler. An example of a simple process orchestration and choreography specification in BPMN is shown in Figure 4, taken from the BPMN 1.1 specification [3]. The figure shows an abstract process Patient and a concrete process Doctor’s office. The Doctor’s office process orchestration is a simple sequence of tasks. The dotted lines between the two processes represent an initial and incomplete description of the choreography by showing the messages flowing between the two processes.4

Fig. 4. Choreographies and orchestrations in the Doctor’s Office example process 4

Note that the clarification and formal definition of the semantics of BPMN is another focus area of our work. However, developing the fundamental techniques for a Business-IT compiler does not require BPMN as a prerequisite. Related well-defined languages such as Petri nets or workflow graphs can also be assumed. Nevertheless, we plan to apply our techniques to BPMN due to the growing practical relevance of the language.

Towards a Compiler for Business-IT Systems

11

Problem 1: Clarify the role of orchestrations and choreographies in the compiler. Our compiler needs to be able to analyze orchestrations as well as choreographies. However, it is not fully clear at which phase choreography information is relevant for the compilation. It is clearly relevant in the assembly and linking phase when an entire Business-IT system is built, but one can also imagine that the optimization of an orchestration can be specific to a given choreography in order to better address the desired target architecture. Another fundamental question for the analysis is the detection of control- and dataflow errors. In the context of a process orchestration, verification techniques have been widely used, e.g., [16] to find errors in the specified control flows. To the best of our knowledge, compiler techniques have not yet been considered so far. Verification of business processes is an area of research that has established itself over the last decade. Locating errors in business processes is important in particular because of the side effects that processes have on data. Processes that do not terminate correctly because of deadlocks or processes that exhibit unintended execution traces due to a lack of synchronization often leave data in inconsistent states [17]. Common approaches to process verification usually take a business process model, translate a process model into a Petri net or another form of a state-based encoding and then run a Petri-net analysis tool or model checker on the encoding. Examples are the Woflan tool [18] or the application of SMV or Spin to BPEL verification, e.g., [19,20]. In principle, these approaches make it possible to detect errors in business processes. However, there are severe limitations that so far prevented the adoption of the proposed solutions in industrial tools: – Encodings are usually of exponential size compared to the original size of the process model. – The verification tools in use do not give detailed enough diagnostic information in such a way that they allow an end user to easily correct errors—it has turned out in practice that counterexample traces are unfortunately only rarely pointing to the real cause of an error. – The approaches often make restricting assumptions on the subclass of process models that they can handle. Consequently, the currently available solutions are only partially applicable in practice due to their long runtimes, the lack of suitable diagnostic information, and the restrictions on the defined encodings. In our own work, we have followed a different approach. First, we analyzed hundreds of real-world business processes and identified commonly occurring so-called anti-patterns [21]. Secondly, we used the PST as th unique parse tree of a process model to speed up the verification of the process [7,14]. Each fragment in a PST can be analyzed in isolation because the tree decomposition ensures that a process model is sound if each fragment is sound. Many fragments exhibit a simplified structure and their soundness (i.e., the absence of deadlocks and lack of synchronization errors) can be verified by matching them against patterns and anti-patterns. Only a small number of fragments remains to which verification methods such as model checking must be

12

J. Koehler et al.

Fig. 5. Example of a business process model in BPMN showing an error-handling flow and data

applied. Furthermore, the size of a fragment is usually small in practice, which results in a significant state-space reduction. Consequently, the resulting combination of verification techniques with structural analysis leads to a complete verification method that is low polynomial in practice with worst-case instances only occurring rarely. As each error is local to a fragment, this method also returns precise diagnostic information. Implementation of the work [14] showed that the soundness of even the largest business process models that we observed in practice can be completely analyzed within a few milliseconds. Consequently, the technology can be made available to users of modeling tools where they obtain instant feedback. Patterns and refactoring operations [22,23] can be provided to users to help them correct the detected modeling errors easily. The patterns and refactoring operations take advantage of the fine-grained diagnostic information and the PST to support users in accomplishing complicated editing steps in a semi-automatic and correct manner. With these results, a major step forward has been made. Still, two problems remain. First, the control-flow analysis must be extended to process models that are enriched with the description of error-handling or compensation flow as it is possible in BPMN. Secondly, no sufficient data-flow analysis techniques are yet available to analyze business processes. Figure 5 illustrates two more problems that we propose to investigate in more detail.

Problem 2: Solve the flow separation problem for arbitrary process orchestrations. Figure 5 shows a repetitive process where a task T 1 is executed followed by a task T 2. T 1 has some data object as output. During the execution of T 1, some compensation event can occur that requires task T 3 to execute. When the compensation is finished, the process continues with T 2. BPMN allows business users to freely draw “normal” flows as well as error-handling flows within the same process model. An error-handling flow can branch off in some task interrupting the normal flow and then merge back later into the normal flow. For a process without cycles, it is relatively easy to tell from the process model where normal and error-handling flows begin and end. For processes with cycles, this is much more complicated and constitutes an unsolved problem that we denote as the “flow separation problem.” A solution to this problem requires the definition of the semantics of error-handling flows. Furthermore, an error-handling flow must always be properly linked to a well-defined part of the normal flow, which is usually called the

Towards a Compiler for Business-IT Systems

13

scope. Computing the scope of an error handling flow from an unstructured process model is an open problem.

Problem 3: Transfer and extend data-flow analysis techniques from classical compilers to Business-IT systems compilers. Data-flow analysis for unstructured business process models is also a largely unsolved problem. Figure 5 shows some data object as an output of task T 1. Large diagrams often refer to many different types of data objects as the inputs and outputs of tasks. Furthermore, decision conditions in the branching points of process flows often refer to data objects. Users who work with process models are interested in answering many questions around data such as whether data input is available for a task, whether data can be simultaneously accessed by tasks running in parallel in a process, or whether certain decision conditions can ever become true given certain data, i.e., whether there are flows in the process that can never execute. An immediate candidate is the Concurrent Single Static Assignment approach [24] that we have begun to explore. Data-flow analysis is also a prerequisite to answer questions such as whether a compensation flow really compensates for the effects of a failed normal flow.

Problem 4: Solve the temporal projection problem for arbitrary process orchestrations. Recently, additional knowledge about the process behavior in the form of semantic annotations is added to process models. These annotations take the form of formally specified pre- and postconditions or simple attribute-value pairs. A tool should be able to reason about these semantic annotations, for example to conclude what pre- and postconditions hold for a complex process fragment containing cycles when the control flow is specified and the pre- and postconditions of the individual tasks are known. This problem of computing the consequences of a set of events has been studied as the so-called Temporal Projection problem in the area of Artificial Intelligence (AI) planning [25] and regressing and progression techniques have been developed. Unfortunately, AI plans exhibit a much simpler structure than process models, in particular they are acyclic, i.e., the existing techniques are not directly applicable. A solution to the temporal projection problem is important for the analysis of data flows as well as for the composition of processes (and services). These four research problems address major challenges for the analysis phase of the compiler when investigating a process orchestration, i.e., a single process model. For process choreographies that describe the interaction and communication between several processes, we are mostly interested in termination problems. Can two processes successfully communicate with each other such that both terminate?

Problem 5: Develop scalable methods to verify the termination of a process choreography returning detailed diagnostic information in case of failure. If a process choreography is fully specified, this question can be precisely answered. Even in the case of abstract models and underspecified choreographies such as in the

14

J. Koehler et al.

example of Figure 4, interesting questions can be asked and answered. For example, which flow constraints must the abstract Patient process satisfy such that a successful communication with the Doctor’s office is possible? Previous work, notably the research on operating guidelines [26,27,28] has provided an initial answer to these questions. The proposed analysis techniques are based on Petri nets, but do not yet scale sufficiently well. Similar to the case of process orchestrations, we are also interested in precise diagnostic information when verifying choreographies. 4.3 Translation and Intermediate Code Generation For the translation phase, we consider one problem as especially important and want to restrict us to this problem, namely the translation from unstructured BPMN to structured BPEL [2].

Problem 6: Define a translation from BPMN to BPEL and precisely characterize the maximal set of BPMN diagrams that are translatable to structured BPEL. An example of relevant related work is [29]. The approach exploits a form of structural decomposition, but not as rigorous as the PST and therefore leads to non-uniform translation results, i.e., the order of application of the translation rules determines the translation output. It is also important to further improve on the initial insights into the classes of BPMN diagrams that are translatable into structured BPEL. Beyond BPEL, one can also imagine that the translation of BPMN to other runtimes, e.g., ones that use communicating state machines is of major practical relevance. 4.4 Optimization The optimization phase for the Business-IT systems compiler is a completely unaddressed research area so far.

Problem 7: Define execution optimization techniques for the Business-IT systems compiler. Classical process optimization, which is mostly performed during a Business Analysis phase, usually focuses on cost minimization. For the compiler, we are envisioning an optimization of processes with respect to their execution on the planned target architecture, but not so much a cost optimization of the process itself. One advantage of compilers is their ability to support multiple platforms. Different architectures, including different styles of SOA, require and enable differences in the process implementation. Optimizations such as load balancing or clustering have for example been studied in the context of J2EE applications [30]. We have some initial insights, but first of all the main goal must be to clarify what can and should happen during the optimization phase.

Towards a Compiler for Business-IT Systems

15

4.5 Final Assembly and Linking Further Optimization For the assembly and linking phase, we see two problem areas that are of particular interest. First, we propose to further study several well-defined synthesis problems. In the literature, two instances of process synthesis problems have been investigated so far: On the one hand, there is the Web service composition problem that is mostly tackled using AI planning techniques [31,32].

Problem 8: Redefine the Web service composition problem such that it is grounded in realistic assumptions and delivers scalable solutions. Web service composition tries to assemble a process orchestration from a predefined set of services. It is commonly assumed that the goal for the composition is explicitly given and that services are annotated with pre- and postconditions. Unfortunately, both assumptions are rarely satisfied in practice. In particular, business users usually have a rather implicit understanding of their composition goals. We cannot expect these users to explicitly formulate their goals in some formal language. Furthermore, the processes returned by the proposed methods for service composition are very simple and resemble more those partially-ordered plans as studied by the AI planning community than those processes modeled by BPMN diagrams. The second problem is the adapter synthesis problem, which is addressed by combining model checking techniques with more or less intelligent “guess” algorithms [33,34]. Adapter synthesis tries to resolve problems in a faulty choreography by generating an additional process that allows existing partners to successfully communicate.

Problem 9: Redefine the adapter synthesis problem by taking into consideration constraints that occur in business scenarios. The problem is inherently difficult in particular due to the unconstrained formulation in which it is studied. Usually, the goal is to generate “some” adapter without formulating any further constraints. Consequently, an infinite search space is opened up and the methods are inherently incomplete. In addition, the synthesized adapters must be verified, because the correctness of the synthesis algorithms is usually not guaranteed. There is thus a wide gap between the currently proposed techniques and the needs of a practically relevant solution. A first goal must therefore be to formulate practically relevant variants of the service composition and adapter synthesis problems. Secondly, solutions to these problems must be worked out that make realistic assumptions, scale to real-world problems and are accepted by the commercial as well as the academic world. An initial goal for these last two research problems is thus to identify realistic problem formulations. For the web composition problem, this means to replace the assumptions of explicit goals and pre- and postconditions by the information that is available in real-world use cases of service composition. Furthermore, the composition methods must be embedded into an approach based on iterative process modeling where a human user is involved, similar to what has been studied by the AI planning community under the term of so-called mixed-initiative approaches. It also seems to be a promising approach to combine such approaches with pattern-based authoring methods similar in

16

J. Koehler et al.

spirit to those known from the object-oriented software engineering community [35], i.e., to provide users with predefined composition problems and proven solutions in the form of composition patterns that they “only” need to instantiate and apply to their problems. The second problem area for the assembly and linking phase focuses on those architectural design decisions that must be taken when compiling business processes to IT systems.

Problem 10: Demonstrate how IT architectural knowledge and decisions are used within the compiler. Today, these decisions are taken by IT architects mostly working with paper and pen. Decisions are not formally represented in tools and no decision-making support is available. Consequently, architectural decisions are not available in a form that they can really be used by the Business-IT systems compiler. Recent work by others and us has shown that architecturally decision making can be systematically supported and that decision alternatives, drivers and dependencies can be explicitly captured in tools and injected into a code-generating process [36,37,38,39]. By separating and validating the architectural decisions, design flaws can be more easily detected and a recompilation of a system for a different architecture is becoming more feasible. With this list of ten specific research problems, the vision of a compiler for BusinessIT systems is broken down into a specific set of key problems. We believe that a solution of these problems constitutes the essential cornerstones for such a compiler. The positioning of the problems within the various compilation phases makes it possible to tackle them systematically as well as study their relationships and dependencies, and to solve the problems under realistic boundary constraints. We believe that the compiler vision is a key to overcome the most urgent problems in the BPM and SOA space. Today, BPM and SOA applications are built from business process models that were drawn in modeling tools that offer little analytical or pattern-based support. From the process analysis models, design models are created by hand by manually translating and refining the information contained in the analysis model. Usually, the direct linkage between analysis and design gets lost during this step. Changes made at the design level are rarely reflected back at the analysis level. Commonly, the business processes are modeled in isolation. Their interdependencies and communication, their distributed side effects on shared data are rarely captured in models, but remain hidden in hand-written code. Thus, building the applications is expensive, resource-intensive, and often ad-hoc. The resulting BPM and SOA systems are hard to test, to maintain, and to change. A compiler significantly increases the quality of the produced solution and provides clearer traceability. Approaches of manual translation are replaced by tool-supported refinement steps guided by detailed diagnostic information. When embedding the compiler into a development environment supporting the life cycle of process models in horizontal (distributed modeling) and vertical (refinement) scenarios, versions of the process models can be tagged, compared, and merged. Alternative views on the processes for different purposes can also be more easily provided.

Towards a Compiler for Business-IT Systems

17

The optimization of Business-IT systems with respect to their execution becomes possible, which can be expected to lead to systems with greater flexibility making it easier for businesses to follow the life cycle of process innovation.

5 Conclusion In this paper, we proposed the vision of a compiler for Business-IT systems that takes business process specifications described at various degrees of detail as input and compiles them into executable IT systems. We defined ten research problems that have to be solved towards creating a compiler for Business-IT systems. Our vision allows us to position problems in a consistent and comprehensive framework that have previously been tackled in isolation. None of the presented research problems is new. In fact, many research projects have been initiated around them. However, as we tried to outline in the previous discussion, none of these projects has been truly successful, because the developed solutions commonly fail in practice: they do either not scale to the size of real-world examples, they do not provide users with the information that they need, or they rely on assumptions that do not hold in practice. However, many of these research projects have delivered interesting partial solutions that are worth to be preserved and integrated into a compiler for Business-IT systems. Consequently, many of these results have to be combined with novel “gap-closing” technology that still has to be developed and placed within the vision of the compiler. In many cases, the gap is in fact quite wide, requiring researchers to leave established solution approaches and develop much more than a small delta on top of existing research results. The ten research problems have been defined at different levels of abstraction. Some are concrete, while others first have to be addressed at the conceptual level before they can be refined into a concrete set of problems. We believe that this mix makes the proposed problems particularly interesting and will enable researchers to drive progress in complementary strands of work. The positioning of these ten problems within the various compilation phases makes it possible for researchers to tackle them systematically, study their interrelationships, and solve the problems under realistic boundary constraints.

References 1. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., Kr¨amer, B.J.: Service-oriented computing: A research roadmap. In: Dagstuhl Seminar Proceedings on Service-Oriented Computing (2006) 2. Jordan, D., et al.: Web services business process execution language (WSBPEL) 2.0 (2007), http://www.oasis-open.org/committees/wsbpel/ 3. OMG: Business Process Modeling Notation Specification, Version 1.1 (2007) 4. Reichert, M., Dadam, P.: ADEPT Flex - supporting dynamic changes of workflows without losing control. Journal of Intelligent Information Systems 10(2), 93–129 (1998) 5. Rinderle, S., Reichert, M., Dadam, P.: Disjoint and overlapping process changes: Challenges, solutions, applications. In: Chung, S. (ed.) OTM 2004. LNCS, vol. 3290, pp. 101–120. Springer, Heidelberg (2004)

18

J. Koehler et al.

6. Muchnik, S.: Advanced Compiler Design and Implementation. Morgan Kaufmann, San Francisco (1997) 7. Vanhatalo, J., V¨olzer, H., Leymann, F.: Faster and more focused control-flow analysis for business process models through SESE decomposition. In: Kr¨amer, B.J., Lin, K.-J., Narasimhan, P. (eds.) ICSOC 2007. LNCS, vol. 4749, pp. 43–55. Springer, Heidelberg (2007) 8. Vanhatalo, J., V¨olzer, H., Koehler, J.: The Refined Process Structure Tree. In: Dumas, M., Reichert, M., Shan, M.-C. (eds.) BPM 2008. LNCS, vol. 5240, pp. 100–115. Springer, Heidelberg (2008) 9. Johnson, R., Pearson, D., Pingali, K.: The program structure tree: Computing control regions in linear time. In: ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 1994), pp. 171–185 (1994) 10. Ananian, C.S.: The static single information form. Master’s thesis, Massachusetts Institute of Technology (September 1999) 11. Valdes-Ayesta, J.: Parsing Flowcharts and series-parallel graphs. PhD thesis, Stanford University (1978) 12. Tarjan, R.E., Valdes, J.: Prime subprogram parsing of a program. In: 7th ACM SIGPLANSIGACT Symposium on Principles of Programming Languages, pp. 95–105. ACM, New York (1980) 13. Ehrig, H., Engels, G., Kreowski, H.-J., Rozenberg, G.: Handbook of Graph Grammars and Computing by Graph Transformation, vol. 2. World Scientific, Singapore (1999) ´ 14. Favre, C.: Algorithmic verification of business process models. Master’s thesis, Ecole Polytechnique F´ed´erale de Lausanne (August 2008) 15. K¨uster, J.M., Gerth, C., F¨orster, A., Engels, G.: Detecting and resolving process model differences in the absence of a change log. In: Dumas, M., Reichert, M., Shan, M.-C. (eds.) BPM 2008. LNCS, vol. 5240, pp. 244–260. Springer, Heidelberg (2008) 16. Baresi, L., Nitto, E.D.: Test and Analysis of Web Services. Springer, Heidelberg (2007) 17. Leymann, F., Roller, D.: Production Workflow. Prentice Hall, Englewood Cliffs (2000) 18. Verbeek, H.M.W., Basten, T., van der Aalst, W.M.P.: Diagnosing workflow processes using WOFLAN. The Computer Journal 44(4), 246–279 (2001) 19. Fu, X., Bultan, T., Su, J.: Analysis of interacting BPEL Web Services. In: 13th Int. Conference on the World Wide Web (WWW 2004), pp. 621–630. ACM, New York (2004) 20. Trainotti, M., Pistore, M., Calabrese, G., Zacco, G., Lucchese, G., Barbon, F., Bertoli, P.G., Traverso, P.: ASTRO: Supporting Composition and Execution of Web Services. In: Benatallah, B., Casati, F., Traverso, P. (eds.) ICSOC 2005. LNCS, vol. 3826, pp. 495–501. Springer, Heidelberg (2005) 21. Koehler, J., Vanhatalo, J.: Process anti-patterns: How to avoid the common traps of business process modeling. IBM WebSphere Developer Technical Journal 10(2+4) (2007) 22. Koehler, J., Gschwind, T., K¨uster, J., Pautasso, C., Ryndina, K., Vanhatalo, J., V¨olzer, H.: Combining quality assurance and model transformations in business-driven development. In: Sch¨urr, A., Nagl, M., Z¨undorf, A. (eds.) AGTIVE 2007. LNCS, vol. 5088, pp. 1–16. Springer, Heidelberg (2008) 23. Gschwind, T., Koehler, J., Wong, J.: Applying patterns during business process modeling. In: Dumas, M., Reichert, M., Shan, M.-C. (eds.) BPM 2008. LNCS, vol. 5240, pp. 4–19. Springer, Heidelberg (2008) 24. Lee, J., Midkiff, S.P., Padua, D.A.: Concurrent static single assignment form and const propagation for explicitly parallel programs. In: Huang, C.-H., Sadayappan, P., Sehr, D. (eds.) LCPC 1997. LNCS, vol. 1366, pp. 114–130. Springer, Heidelberg (1998) 25. Nebel, B., B¨ackstr¨om, C.: On the computational complexity of temporal projection, planning, and plan validation. Artificial Intelligence 66(1), 125–160 (1994) 26. Massuthe, P., Reisig, W., Schmidt, K.: An operating guideline approach to the soa. AMCT 1(3), 35–43 (2005)

Towards a Compiler for Business-IT Systems

19

27. Lohmann, N., Massuthe, P., Wolf, K.: Operating guidelines for finite-state services. In: Kleijn, J., Yakovlev, A. (eds.) ICATPN 2007. LNCS, vol. 4546, pp. 321–341. Springer, Heidelberg (2007) 28. Massuthe, P., Wolf, K.: An algorithm for matching nondeterministic services with operating guidelines. Int. Journal of Business Process Integration and Management 2(2), 81–90 (2007) 29. Ouyang, C., Dumas, M., ter Hofstede, A.H.M., van der Aalst, W.M.P.: From BPMN process models to BPEL Web Services. In: IEEE Int. Conference on Web Services (ICWS 2006), pp. 285–292 (2006) 30. Sriganesh, R.P., Bose, G., Silvermanohn, M.: Mastering Enterprise JavaBeans 3.0. John Wiley, Chichester (2006) 31. Rao, J., Su, X.: A survey of automated web service composition methods. In: Cardoso, J., Sheth, A.P. (eds.) SWSWPC 2004. LNCS, vol. 3387, pp. 43–54. Springer, Heidelberg (2005) 32. Hoffmann, J., Bertoli, P., Pistore, M.: Web service composition planning, revisted: In between background theories and initial state uncertainty. In: 22nd AAAI Conference on Artificial Intelligence (AAAI 2007), pp. 1013–1018 (2007) 33. Bertoli, P., Hoffmann, J., L´ecu´e, F., Pistore, M.: Integrating discovery and automated composition: From semantic requirements to executable code. In: IEEE Int. Conference on Web Services (ICWS 2007), pp. 815–822. IEEE, Los Alamitos (2007) 34. Brogi, A., Popescu, R.: Automated generation of bpel adapters. In: Dan, A., Lamersdorf, W. (eds.) ICSOC 2006. LNCS, vol. 4294, pp. 27–39. Springer, Heidelberg (2006) 35. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (1995) 36. Kruchten, P., Lago, P., van Vliet, H.: Building up and reasoning about architectural knowledge. In: Hofmeister, C., Crnkovi´c, I., Reussner, R. (eds.) QoSA 2006. LNCS, vol. 4214, pp. 43–58. Springer, Heidelberg (2006) 37. Jansen, A., Bosch, J.: Software architecture as a set of architectural design choices. In: 5th IFIP Conference on Software Architecture (WICSA 2005), pp. 109–120. IEEE, Los Alamitos (2005) 38. Tyree, J., Akerman, A.: Architecture decisions: Demystifying architecture. IEEE Software 22(2), 19–27 (2005) 39. Zimmermann, O., Zduhn, U., Gschwind, T., Leymann, F.: Combining pattern languages and architectural decision models into a comprehensive and comprehensible design method. In: 8th IFIP Conference on Software Architecture (WICSA 2008), pp. 157–166. IEEE, Los Alamitos (2008)

Towards Use-Cases Benchmark Bartosz Alchimowicz, Jakub Jurkiewicz, Jerzy Nawrocki, and Mirosław Ochodek Poznan University of Technology, Institute of Computing Science, ul. Piotrowo 3A, 60-965 Poznań, Poland {Bartosz.Alchimowicz,Jakub.Jurkiewicz,Jerzy.Nawrocki, Miroslaw.Ochodek}@cs.put.poznan.pl

Abstract. In the paper an approach to developing a use-cases benchmark is presented. The benchmark itself is a referential use-case-based requirements specification, which has a typical profile observed in real projects. To obtain this profile an extensive analysis of 432 use cases coming from 11 projects was performed. Because the developed specification represents those found in real projects, it might be used in order to present, test, and verify methods and tools for use-case analysis. This is especially important because industrial specifications are in most cases confident, and they might not be used by researchers who would like to replicate studies performed by their colleagues. Keywords: Use cases, Requirements engineering, Metrics, Benchmark.

1

Introduction

Functional requirements are very important in software development. They impact not only the product but also test cases, cost estimates, delivery date, and user manual. One of the forms of functional requirements are use cases introduced by Ivar Jacobson about 20 years ago. They are getting more and more popular in software industry and they are also a subject of intensive research (see e.g. [2,3,8,9,20]). Ideas presented by researches must be empirically verified (in best case, using industrial data) and it should be possible to replicate a given experiment by any other researcher [19]. In case of use cases research it means that one should be able to publish not only his/her results but also the functional requirements (use cases) that has been used during the experiment. Unfortunately, that is very seldom done because it is very difficult. If a given requirements specification has a real commercial value, it will be hard to convince its owner (company) to publish it. Thus, to make experiments concerning use cases replicable, one needs a benchmark that would represent use cases used in real software projects. In the paper an approach to construct use-cases benchmark is presented. The benchmark itself is the use-cases-based requirements specification, which has a 

This research has been financially supported by the Polish Ministry of Science and Higher Education grant N516 001 31/0269.

Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 20–33, 2011. c IFIP International Federation for Information Processing 2011 

Towards Use-Cases Benchmark

21

typical profile observed in requirements coming from the real projects. To derive such a profile an extensive analysis of 432 use cases was performed. The paper is organised as follows. In Section 2 a model of use-cases-based requirements specification is presented. This model is further used in Section 3, which presents an analysis of the use-cases, coming from eleven projects. Based on the analysis a profile of the typical use-case-based specification is derived, which is used to create a benchmark specification in Section 4. Finally, a case study is described in Section 5, which presents a typical usage of the benchmark specification in order to compare tools for use-case analysis.

2

Benchmark-Oriented Model of Use-Case-Based Specification

Although use cases have been successfully used in many industrial projects (Neil et al. [16] reported that 50% of projects have their functional requirements presented in that form), they have never been a subject of any recognisable standardisation. Moreover, since their introduction by Ivar Jacobson [13] many approaches for their development were proposed. Russell R. Hurlbut [11], gathered fifty-seven contributions concerning use cases modeling. Although, all approaches share the same idea of presenting actor’s interaction with the system in order to obtain his goal, they vary in a level of formalism and presentation form. Thus it is very important to state what is understood by the term usecases-based requirements specification. To mitigate this problem a semi-formal model of use-cases-based requirements specification has been proposed (see figure 1). It incorporates most of the bestpractices presented in [1,5]. It still allows to create specification that contains only scenario (or nonstructured story) and actors, which is enough to compose small but valuable use-case, as well as extend it with other elements, for example extensions (using steps or stories), pre- and post-conditions, notes or triggers. Unfortunately, understanding the structure of specification is still not enough in order to construct a typical use-cases-based specification. What is missing, is the quantifiable data concerning the number of model-elements and proportions between them1 . In other words, one meta-question has to be asked for each element of the model - "how many?".

3

Analysis of Use-Cases-Based Specifications Structure

In order to discover the profile of typical-specification, data from various projects was collected and analysed. As a result a database called UCDB (Use Cases Database) [6] has been created. At this stage it stores data from 11 projects with the total number of 432 use cases (basic characteristics of requirements specifications as well as projects descriptions are grouped in table 1). 1

A number/proportion of any element of the model will be further addressed as a property of the specification.

22

B. Alchimowicz et al. Requirements Specification *

1

Business Object

* Actor

+Name +Description

+Name +Descrip tion

1

1

*

+main-actors +secondary -actors

+Title

*

*

Use Case

1 Referenced Element

+sub-scenario

+Description

* *

1

Scenario 1

1 S tep

*

+main-scenario

1

* Trigger

1 Goal Level

0..1

1..*

* +pre-conditions +p ost-conditions * * Condition

+Description

+Text 1

*

1 Business

Story +Text

1 0..1

User

Sub-function

Extension +Event_Text

Fig. 1. Use-Cases-based functional requirements specification model

All of the specifications have been analysed in order to populate the model with the information concerning average number of its elements occurrence and some additional quantifiable data. One of the interesting findings is that 79.9% of the main-scenarios in the use cases consist of 3-9 steps, which means that they fulfil the guidelines proposed by Cockburn [5]. What is more 72.9% of the analysed use cases are augmented with the alternative scenarios (extensions). There are projects which contains extensions for all steps in main scenario, however on the average use case contains 1.5 extension. Detailed information regarding number and distributions of steps in both - main scenario and extensions, is presented in figure 2. Another interesting observation, concerning the structure of use cases, is that the sequences of steps performed by the same actor, frequently contains more than one step. What is even more interesting this tendency is more visible in case of main actor’s steps (37.3% of main actor’s steps sequences are longer than one step, and only 19.4% in case of secondary actor - in most cases system being built). This is probably because actions performed by main actor are more important, from the business point of view. This is contradict to the concept of transactions in use cases presented by Ivar Jacobson [12]. Jacobson enumerated four types of actions which may form together use-case transaction. Only one of them belongs to a main actor (user request action). The rest of them are system actions: validation, internal state change, and response. It might look

Towards Use-Cases Benchmark

23

ID

Specification Language

Origin

All

Business

User

Subfunction

Table 1. Analysed projects requirements-specifications (origin: industry - project developed by software development company, s2b - project developed by students for external organisation, external - specification obtained from the external source which is freely accessible through the Internet - this refers to two specifications: UKCDR [21], PIMS [18]; projects D and K come from the same organisation)

Project A

English

S2B

17

0%

76%

24%

Web & standalone application for managing members of organization

Project B

English

S2B

37

19%

46%

35%

Web-based Customer Relationship Management (CRM) system

Project C

English External

39

18%

44%

33%

UK Collaboration for a Digital Repository (UKCDR)

Project D

Polish

Industry

77

0%

96%

4%

Web-based e-government Content Management System (CMS)

Project E

Polish

S2B

41

0%

100%

0%

Web-based Document Management System (DMS)

Project F

Polish

Industry

10

0%

100%

0%

Web-based invoices repository for remote accounting

Project G

English External

90

0%

81%

19%

Protein Information Management System (PIMS)

Project H

Polish

Industry

16

19%

56%

25%

Integration of two sub-system s in ERP scale system

Project I

Polish

Industry

21

38%

57%

5%

Banking system

Project J

Polish

Industry

9

0%

67%

33%

Single functional module for the webbased e-commerce solution

Project K

Polish

Industry

75

0%

97%

3%

Web-based workflow system with Content Management System (CMS)

Number of use cases Description

that those actions should frequently form together longer sequences. However, 80.6% of steps sequences performed by system consisted of single step only. The distributions and number of steps in main actor’s sequences are presented in figure 3. If we look deeper into the textual representation of the use cases, some interesting observation concerning their semantic might be made. One of them regards the way use-cases authors describe validations actions. Two different approaches are observed. The most common is to use extensions to represent alternative system behaviour in case of verification-process failure (46.6% of extensions have this kind of nature). Second one, and less frequent, is to incorporate validation actions into steps (e.g. System verifies data). This kind of actions are observed only in 3.0% of steps. There is also yet another interesting semantic structure used to represent alternative execution paths - conditional clauses (which in fact, are rather deprecated). Fortunately this kind of statements are observed only in 3.2% of steps (and they occur intensively only in 2 projects).

0.00 1

3 5 7 9 11 14 Number of steps in extension

10

A B C D E

F G H

I

J

K

J

K

d)

2

4

6

8

Project Number of steps in extension

0.0

0.1

Density 0.2 0.3

0.4

1 3 5 7 9 11 14 Number of steps in main scenario c)

b)

5

Density 0.10 0.20

a)

15

B. Alchimowicz et al.

Number of steps in main scenario

24

A

B

C

D

F

G

H

I

Project

Fig. 2. Scenarios lengths in analysed use cases a) histogram presents the number of steps in main scenario (data aggregated from all of the projects), b) box plot presents the number of steps in main scenario (in each project), c) histogram presents the number of steps in extension (data aggregated from all of the projects), d) box plot presents the number of steps in extension (in each project, note that project E was excluded because it has all alternative scenarios written as stories)

Analysed properties can be classified into two separate classes. The first one contains properties which are observed in nearly all of the projects, with comparable intensity. Those kind of properties are seem to be independent from the specification they belong to (from its author’s writing style). The second class is an opposite one, and includes properties wich are either characteristic only for a certain set of use cases or their occurrence in different specifications are in between of two extremes - full presence or marginal/none. Such properties are project-dependent. More detailed description of analysed requirements specifications is presented in table 2.

Towards Use-Cases Benchmark

b)

100%

90%

80%

80%

70%

Density

100%

90%

62.7%

50% 40% 30%

80.6%

70%

60%

Density

a)

25

9.8% 3.9% 3.5%

10%

50% 40% 30%

20.1%

20%

60%

0%

13.3%

20%

3.3% 1.9% 0.9%

10% 0%

1

2

3

4

>4

Main actor's steps sequence length

1 2 3 4 >4 Secondary actor's steps sequence length

Fig. 3. Distributions of actors steps-sequences lengths in analysed use cases, a) histogram presents the length of the steps sequences performed by main actor, b) histogram presents length of the steps sequences performed by secondary actor - e.g. System

4

Building Referential Specification

Combining use-cases model and average values coming from the analysis, a profile of the typical use-cases-based requirements specification can be derived. In such specification all properties would appear with the typical intensity. In other words, analysis performed on such document could be perceived as an every-day task for use-cases analysis tools. There might be at least two approaches to acquire instance of such specification. The first one would be to search for the industrial set of use cases, which would fulfil given criteria. Unfortunately, most of industrial documents are confidential, therefore they could not be used at large scale. The second, obvious approach would be to develop such specification from scratch. If it is built according to the obtained typical-specification profile, it might be used instead of industrial specification. Since it would describe some abstract system it can be freely distributed and used by anyone. Therefore, we would like to propose approach to develop an instance of the referential specification for the benchmarking purpose. The document is available at the web site [6] and might be freely used for further research. 4.1

Specification Domain and Structure

It seems that large number of tools for the use-cases analysis have their roots in the research community. Therefore the domain of the developed specification should be easy to understand especially for the academia staff. One of the wellrecognised processes at universities is a students admission process. Although

Requirements specification independent

38.0% 13.7% 1.98 1.69 48.5% 10.6% 36.3% 3.2% 6.3% 71.9% 28.1%

13.3% 3.3% 1.9% 0.9%

2 3 4 >4

Use cases with additional description Number of use cases with sub-scenario Mean Number of steps in sub-scenario SD Use cases with pre-conditions Use cases with post-conditions Use cases with triggers Steps with conditional clauses Number of steps with reference to use cases Number of extensions with scenario Number of extensions with stories

Secondary actor's steps sequence length in main scenario

Main actor's steps sequence length in main scenario

62.7% 20.1% 9.8% 3.9% 3.5% 80.6%

1 2 3 4 >4 1

Mean SD Mean SD

Steps with validation actions Extensions which are validations

Number of steps in extension

Number of extensions in use case

Use cases with extensions

Number of steps in main scenario

432 4.87 2.48 72.9% 1.50 1.84 2.51 1.62 3.0% 46.6%

Number of use cases

Mean SD

Overall

Property

0.0% 0.0% 0.00 N/A 82.4% 0.0% 100% 1.2% 0.0% 27.3% 72.7%

17.4% 0.0% 0.0% 0.0%

42.3% 23.1% 26.9% 7.7% 0.0% 82.6%

0.0% 0.0% 0.00 N/A 100% 0.0% 100% 1.1% 0.5% 100% 0.0%

3.7% 0.0% 0.0% 0.0%

93.1% 3.5% 3.5% 0.0% 0.0% 96.3% 29.6% 0.0% 2.5% 0.0%

37.0% 34.8% 16.3% 6.5% 5.4% 67.9% 0.0% 0.0% 0.0% 0.0%

61.9% 36.1% 0.0% 0.0% 2.1% 100% 0.0% 0.0% 0.0% 0.0%

87.5% 12.5% 0.0% 0.0% 0.0% 100% 8.0% 2.0% 0.0% 0.0%

91.7% 0.0% 8.3% 0.0% 0.0% 90.0% 16.7% 33.3% 0.0% 0.0%

47.4% 0.0% 31.6% 21.1% 0.0% 50.0%

43.8% 25.0% 0.0% 18.8%

52.4% 19.1% 23.8% 0.0% 4.8% 12.5%

37.5% 0.0% 0.0% 0.0%

50.0% 42.9% 7.1% 0.0% 0.0% 62.5%

14.8% 7.4% 4.1% 1.6%

52.6% 16.4% 12.9% 8.6% 9.5% 72.1%

Project F G H I J K 10 90 16 21 9 75 3.90 5.10 3.38 4.33 3.67 6.36 1.20 2.41 0.50 2.01 1.32 3.25 100% 68.9% 81.3% 90.5% 55.6% 98.7% 1.00 1.28 2.94 2.33 1.00 2.69 0.00 1.30 2.98 1.58 1.58 2.91 1.10 2.77 2.30 1.64 1.44 3.09 0.32 1.87 0.65 0.67 0.53 1.80 0.0% 0.0% 27.8% 17.6% 3.0% 0.0% 100% 50.4% 78.7% 89.8% 100% 15.3%

100% 0.0% 0.0% 0.0% 100% 56.3% 100% 0.0% 6.7% 0.0% 32.5% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 44.2% 0.00 3.20 0.00 0.00 0.00 0.00 0.00 0.00 1.09 N/A 2.02 N/A N/A N/A N/A N/A N/A 0.29 0.0% 0.0% 97.6% 0.0% 0.0% 0.0% 23.8% 77.8% 0.0% 97.4% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100% 0.0% 100% 0.0% 0.0% 68.8% 57.1% 0.0% 0.0% 17.4% 0.3% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 9.0% 0.0% 0.0% 0.0% 25.6% 14.2% 0.0% 0.0% 6.1% 33.3% 8.1% 87.3% 0.0% 100% 100% 100% 100% 100% 100% 91.9% 12.7% 100% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

22.2% 0.0% 5.6% 0.0%

88.6% 6.8% 4.6% 0.0% 0.0% 72.2%

A B C D E 17 37 39 77 41 4.76 4.92 2.95 4.34 5.78 0.97 1.46 2.69 2.25 1.26 94.1% 51.4% 41.0% 55.8% 92.7% 1.29 0.57 0.95 0.92 1.63 0.77 0.60 1.72 1.12 0.62 1.80 2.52 1.00 1.45 N/A 0.84 0.87 0.00 0.59 N/A 3.7% 5.5% 11.3% 1.8% 0.0% 9.1% 76.2% 64.9% 63.4% 40.3%

26 B. Alchimowicz et al.

Table 2. Use-Cases Database analysis according to the presented requirements specification model (see section 2)

Requirements specification dependent

Towards Use-Cases Benchmark

27

developed specification will describe hypothetical process and tools, it should be easy to understand for anyone who have ever participated in a similar process. Another important decision concerns the structure of the specification (number of actors, use cases and business objects). Unfortunately the decision is rather arbitral, because number of use cases, actors and business objects may depend on the size of the system and level of details incorporated into its description. In this case a median number of use cases and actors from the UCDB set has been used as a number of use cases and actors in the constructed specification. The final specification consist of 7 actors (Administrator, Candidate, Bank, Selection committee, Students Management System, System, User), 37 use cases (3 business, 33 user, and 1 sub-function level), and 10 business objects. 4.2

Use Cases Structure

A breadth-first rule has been followed in order to construct referential specification. Firstly, all use cases were titled and augmented with descriptions. Secondly, all of them were filled with main scenarios and corresponding extensions. During that process all changes made in specification were recorded in order to check conformance with the typical profile. This iterative approach was used until the final version of the specification has been constructed. Its profile is presented in table 3, in comparison to the corresponding average values from the UCDB projects analysis (main actor’s step sequences lengths for referential specification, are additionally presented in figure 4). The most important properties are those which are observed in all of the specifications (specification independent). In case of those metrics most values in the referential document are very close to those derived from the analysis. This situation differs in case of properties which were characteristic only for certain projects (or variability between projects were very high). If the constructed specification is suppose to be a typical one, it should not be biased by features observed only in some of the industrial specifications. Therefore dependent properties were also incorporated into the referential use cases, however they were not a subject of the tunning process.

5

Benchmarking Use Cases - Case Study

Having the example of the typical requirements specification, one can wonder how it could be used. Firstly, researchers who construct methods and tools in order to analyse use cases often face the problem of evaluating their ideas. Using some specification coming from the industrial project is a typical approach, however, this cannot lead to the conclusion that the given solution would give the same results for other specifications. The situation looks different when the typical specification is considered, then researchers can assume that their tool would work for most of the industrial specifications. Secondly, analysts who want to use some tools to analyse their requirements can have a problem to choose the best tool that would meet their needs. With the typical specification in mind

28

B. Alchimowicz et al.

Table 3. Referential specification profile in comparison to the average profile derived from the UCDB use-cases analysis Referential Specification

Property

Admission System

Number of steps in main scenario

Mean SD

Use Cases with extensions Number of extensions in use case Number of steps in extension

Mean SD Mean SD

Steps of validation nature Extensions of validation nature Steps with conditional clauses

Main actor's steps sequence length in main scenario

Secondary actor's steps sequence length in main scenario

1 2 3 4 >4 1 2 3 4 >4

4.89 1.47 70.3% 1.50 0.69 2.49 2.12 2.2% 46,2% 0.6% 62.3% 21.3% 9.8% 3.3% 3.3% 80.7% 12.9% 4.8% 1.6% 0.00%

Observed in UseCases Database 4.87 2.48 72.92% 1.50 1.84 2.51 1.62 3.0% 46.6% 3.2% 62.7% 20.1% 9.8% 3.9% 3.5% 80.6% 13.3% 3.3% 1.9% 0.9%

it can be easier to evaluate the available solutions and choose the most suitable one. To conclude the example of the typical requirements specification can be used: – to compare two specifications and asses how the given specification is similar to the typical one – to asses the time required for a tool to analyse requirement specification – to asses the quality of a tool/method – to compare tools and choose the best one In order to demonstrate the usage of the constructed specification we have conducted a case study. As a tool for managing requirements in form of use cases we chose the UC Workbench tool [15], which has been developed at Poznan University of Technology since the year 2005. Additionally we used the set of tools for defects detection [4] to analyse the requirements. The aim of the mentioned tools is to find potential defects and present them to analyst during the development of the requirements specification. The tools are based on the Natural Language Processing (NLP) methods and use Standford parser [7] and/or OpenNLP [17] tools to perform the NLP analysis of the requirements.

Towards Use-Cases Benchmark

a)

b)

100%

90%

80%

80%

62.3% Density

50% 40%

21.3%

30%

80.7%

70%

60%

Density

100%

90% 70%

29

20%

50% 40% 30%

9.8%

10%

60%

12.9%

20%

3.3% 3.3%

4.8% 1.6% 0.0%

10%

0%

0%

1

2

3

4

>4

1 2 3 4 >4 Secondary actor's steps sequence length

Main actor's steps sequence length

Fig. 4. Distributions of actors steps-sequences lengths in referential specification, a) histogram presents the length of the steps sequences performed by main actor, b) histogram presents length of the steps sequences performed by secondary actor - e.g. System

5.1

Quality Analysis

In order to evaluate the quality of the used tools, a confusion matrix will be used [10] (see table 4). Table 4. Confusion matrix

System answer

Expert answer Yes

No

Yes

TP

FP

No

FN

TN

The symbols used in table 4 are described below: – – – –

T (true) - tool answer that is consistent with the expert decision F (false) - tool answer that is inconsistent with the expert decision P (positive) - system positive answer (defect occurs) N (negative) - system negative answer (defect does not occur)

On the basis of the confusion matrix, following metrics [14] can be calculated:

30

B. Alchimowicz et al.

– Accuracy (AC) - proportion of the total number of predictions that were correct. It is determined using the equation 1. AC =

TP + TN TP + FN + FP + TN

(1)

– True positive rate (TP rate) - proportion of positive cases that were correctly identified, as calculated using the equation 2. T P rate =

TP TP + FN

(2)

– True negative rate (TN rate) is defined as the proportion of negatives cases that were classified correctly, as calculated using the equation: 3. T N rate =

TN TN + FP

(3)

– Precision (PR) - proportion of the predicted positive cases that were correct, as calculated using the equation 4. PR =

TP TP + FP

(4)

The referential use-case specification was analysed by the mentioned tools (to perform the NLP processing Stanford library was used) in order to find 10 types of defects described in [4]. Aggregated values of the above accuracy-metrics are as follows: – – – –

AC = 0.99 TP rate = 0.96 TN rate = 0.99 PR = 0.82

This shows that the developed tools for defects detection are rather good, however, the precision could be better and the researchers could conclude that more investigation is needed in this area. If the researchers worked on their tool using only defect-prone or defect-free specifications the results could be distorted and could lead to some misleading conclusions (e.g. that the tool is significantly better or that it gives very poor outcome). Having access to the typical specification allows the researchers to explore main difficulties the tool can encounter during working with the industrial specifications. 5.2

Time Analysis

One of the main characteristics of a tool being developed is its efficiency. Not only developers are interested in this metric, but also for the users - e.g. when analysts have to choose between two tools which give the same results, they would choose the one which is more efficient. However, it can be hard to asses

Towards Use-Cases Benchmark

31

Table 5. Case-study results (tools are written in Java, so memory was automatically managed – garbage collection) Summarised for all components

English grammar parser only

Mean time Maximal English Overall Overall needed to memory Startup grammar processing processing analyse utilization time [s] parser used time [s] time [s] one step [s] [MB]

Memory usage Initial while memory processing usage [MB] single element [KB]

Stanford

54.37

0.29

212

37.44

0.8

27

547

OpenNLP

31.21

0.17

339

14.58

15.6

226

3925

AC

TP rate

TN rate

PR

Stanford

0.99

0.96

0.99

0.82

OpenNLP

0.99

0.84

0.99

0.79

Quality

the efficiency just by running the tool with any data, as this may result with distorted outcome. Use-cases benchmark gives the opportunity to measure the time, required by a tool to complete its computations, in an objective way. It can be also valuable for researchers constructing tools to consider using different third-party components in their applications. For instance, in case of the mentioned defect-detection tool there is a possibility of using one of the available English grammar parsers. In this case study two of them will be considered - Standford parser and OpenNLP. If one exchanges those components the tool will still be able to detect defects, but its efficiency and accuracy may change. Therefore, the time analysis was performed to asses how using those libraries influence the efficiency of the tool. The overall time required to analyse the typical specification2 for the tool using Stanford parser was 54.37 seconds and for the one with OpenNLP it was 31.21 seconds. Although the first time value seems to be large, the examined tool needed on average 290 ms to analyse a single use-case step, so it should not be a problem to use it in the industrial environment. Of course, when comparing efficiency, one have to remember that other factors (like the quality of the results, memory requirements or the time needed for the initialization of the tools) should be taken into account, as they can also have significant impact on the tool itself. Therefore, time, memory usage and quality analysis is presented in table 5. This summarised statistics allow researchers to choose the best approach for their work. Although this specification describes some abstract system, it shows the typical phenomenon of the industrial requirements specifications. The conducted 2

Tests were performed for the tools in two versions: with Stanford and OpenNLP parsers. Each version of the tools analysed the referential specification five times, on the computer with Pentium Core Duo 2.0GHz processor and 2GB RAM.

32

B. Alchimowicz et al.

case study shows that the developed referential use-case specification can be used in different ways by both researchers and analysts.

6

Conclusions

In the paper an approach to create a referential use-cases-based requirements specification was presented. In order to derive such a specification 432 use cases were analysed. It has proved that some of the use-case properties are project-independent (are observed in most of the projects). They have been used for creating the referential specification. On the other hand, there is also a number of properties which depend very much on the author. In order to present potential usage of the benchmark specification, a case study was conducted. Two sets of tools for defect detection in requirements were compared from the point of view of efficiency and accuracy. In the future it would be beneficial to extend the use-case database with more use-cases coming from commercial projects. This would require an iterative approach to updating the typical-profile as well as the referential specification. Acknowledgments. We would like to thank Piotr Godek, Kamil Kwarciak and Maciej Mazur for supporting us with industrial use cases. This research has been financially supported by the Polish Ministry of Science and Higher Education under grant N516 001 31/0269.

References 1. Adolph, S., Bramble, P., Cockburn, A., Pols, A.: Patterns for Effective Use Cases. Addison-Wesley, Reading (2002) 2. Anda, B., Sjøberg, D.I.K.: Towards an inspection technique for use case models. In: Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering, pp. 127–134 (2002) 3. Bernardez, B., Duran, A., Genero, M.: Empirical Evaluation and Review of a Metrics-Based Approach for Use Case Verification. Journal of Research and Practice in Information Technology 36(4), 247–258 (2004) 4. Ciemniewska, A., Jurkiewicz, J., Olek, Ł., Nawrocki, J.R.: Supporting use-case reviews. In: Abramowicz, W. (ed.) BIS 2007. LNCS, vol. 4439, pp. 424–437. Springer, Heidelberg (2007) 5. Cockburn, A.: Writing effective use cases. Addison-Wesley, Boston (2001) 6. Use Case Database, http://www.ucdb.cs.put.poznan.pl 7. de Marneffe, M.-C., MacCartney, B., Manning, C.D.: Generating typed dependency parses from phrase structure parses. In: Proceedings of the EACL Workshop on Linguistically Interpreted Corpora, LINC (2006) 8. Denger, C., Paech, B., Freimut, B.: Achieving high quality of use-case-based requirements. Informatik-Forschung und Entwicklung 20(1), 11–23 (2005) 9. Diev, S.: Use cases modeling and software estimation: applying use case points. ACM SIGSOFT Software Engineering Notes 31(6), 1–4 (2006)

Towards Use-Cases Benchmark

33

10. Fawcett, T.: Roc graphs: Notes and practical considerations for data mining researchers (2003) 11. Hurlbut, R.: A Survey of Approaches for Describing and Formalizing Use Cases. Expertech, Ltd. (1997) 12. Jacobson, I.: Object-oriented development in an industrial environment. ACM SIGPLAN Notices 22(12), 183–191 (1987) 13. Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object-oriented software engineering: A use case driven approach (1992) 14. Krawiec, K., Stefanowski, J.: Uczenie maszynowe i sieci neuronowe. Wydawnictwo Politechniki Poznańskiej (2004) 15. Nawrocki, J., Olek, Ł.: Uc workbench - a tool for writing use cases. In: Baumeister, H., Marchesi, M., Holcombe, M. (eds.) XP 2005. LNCS, vol. 3556, pp. 230–234. Springer, Heidelberg (2005) 16. Neill, C.J., Laplante, P.A.: Requirements Engineering: The State of the Practice. IEEE Software 20(6), 40–45 (2003) 17. OpenNLP, http://opennlp.sourceforge.net 18. PIMS, http://www.mole.ac.uk/lims/project/srs.html 19. Shull, F.J., Carver, J.C., Vegas, S., Juristo, N.: The role of replications in empirical software engineering. Empirical Software Engineering 13(2), 211–218 (2008) 20. Somé, S.S.: Supporting use case based requirements engineering. Information and Software Technology 48(1), 43–58 (2006) 21. UKCDR, http://www.ukoln.ac.uk/repositories/digirep/index/all_the_scenarios_ and_use_cases_submitted#ukcdr

Automated Generation of Implementation from Textual System Requirements Jan Franc˚ u and Petr Hnˇetynka Department of Distributed and Dependable Systems Faculty of Mathematics and Physics, Charles University in Prague Malostranske namesti 25, 118 00 Prague 1, Czech Republic [email protected], [email protected]

Abstract. An initial stage of a software development is a specification of the system requirements. Frequently, these requirements are expressed in UML and consist of use cases and a domain model. A use case is a sequence of tasks, which have to be performed to achieve a specific goal. The tasks of the use case are written in a natural language. The domain model describes objects used in the use cases. In this paper, we present an approach that allows automated generation of an executable code directly from the use cases written in a natural language. Use of the generation significantly accelerates the system development, e.g. it makes immediate verification of requirements completeness possible and the generated code can be used as a starting point for the final implementation. A prototype implementation of the approach is also described in the paper. Keywords: Use cases, code generation, requirement engineering, natural language.

1

Introduction

Development of software is covered by several stages from which one of the most important is the initial stage — collecting system requirements. These requirements can be captured in many forms but using the Unified Modeling Language (UML) has become an industry standard at least for large and medium enterprise applications. Development with UML [6] is based on modeling the developed system at multiple levels of abstraction. Such a separation helps developers to reflect specific aspects of the designed system on different levels and therefore to get a “whole picture” of the system. Development with the UML starts with defining goals of the system. Then, main characteristics of the system requirements are identified and described. A behavior of the developed system is specified as a set of use cases. A use case is a description of a single task performed in the designed system [2]. The task itself is further divided into a sequence of steps that are performed by communicating entities. These entities are either parts of the system or users of the system. The step of a use case is specified by natural language sentences. The use cases of the Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 34–47, 2011. c IFIP International Federation for Information Processing 2011 

Automated Generation of Implementation

35

system are completed by a domain model that describes entities, which together form the designed system and which are referred in the use cases. Bringing a system from the designing stage to the market is a very timeconsuming and also money-consuming task. A possibility to generate an implementation draft directly from the system requirements would be very helpful for both requirement engineers and developers and it would significantly speed up development of the system and decrease time required to deliver the system to the market and also decrease amount of spent money. The system use cases contain work-flow information and together with the domain model capture all important information and therefore seem to be sufficient for such a generation. But the problem is that use cases are written in natural language and there is a gap to overcome to generate a system code. 1.1

Goals of the Paper

In this paper, we describe an approach, which allows to generate an implementation of a system from the use cases written in a natural language. The process proposed in the paper enables software developers to take an advantage of the carefully written system requirements in order to accelerate the development and to provide immediate feedback for the project’s requirement engineers by highlighting missing parts of the system requirements. The process fits into the incremental development where in each iteration developers can eliminate shortcomings in design. The process can be customized to fit any enterprise application project. Described approach is implemented in a proof-of-the-concept tool and tested on a case study system. To achieve the goals, the paper is structured as follows. Section 2 provides an overview of the UML models and technologies required for a use case analysis. Section 3 shows how our generation tool is employed in application development process and Sec. 4 describes the tool and all generation steps in detail. Section 5 evaluates our approach and the paper is concluded in Sec. 6, where future plans are also shown.

2

Specification of Requirements

The Unified Modeling Language (UML) is a standardized specification language for the software development. Development with UML is based on modeling a system at multiple levels of abstraction in separated models. Each model represented as a set of documents clarifies the abstraction on a particular level and captures different aspects of the modeled system. The UML based metodologies standardize whole development process and ensures that the designed system will meet all the requirements. UML also increases possibilities to reuse existing models and simplifies reuse of an implemented code. In this paper, we work with the UML documents created during the initial stage of the system development, i.e. the requirement specification. Results of the stage are captured in use cases and domain model.

36

2.1

J. Franc˚ u and P. Hnˇetynka

Use Cases

A use case in the context of UML is a description of a process where a set of entities cooperates together to achieve a goal of the use case. The entities in the use case can refer to the whole system, parts of the system, or users. Each use case has a single entity called system under discussion (SuD); from the perspective of this entity, the whole use case is written. An entity with which SuD primarily communicates is called a primary actor (PA). Other entities involved in the use case are called supporting actors (SA). Each use case is a textual document written in a natural language. The book [2] recommends the following structure of the use case: (1) header, (2) main scenario, (3) extensions, and (4) sub-variations. The header contains a name of the use case, SuD entity, primary actor and supporting actors. The main scenario (also called the success scenario) defines a list of steps (also called actions) written as sentences in a natural language that are performed to achieve the goal of the use case. An action can be extended with a branch action, which reflects possible diversions from the main scenario. There are two types of the branch actions: extensions and sub-variations. In an extension, actions are performed in addition to the extended action while in a sub-variation, actions are performed instead of the extended action. The first sub-action of a branch action is called a conditional label and describes necessary condition under which the branch action is performed. The above described structure is not the only possible one — designers can use any structure they like. In our approach, we assume the use cases hold these recommendation as it allows us to process the use case automatically and generate the system implementation. Such an assumption does not limit the whole approach in a significant way, hence the book [2] is widely considered as a “bible” for writing the use cases (in addition, we already have an approach for using use cases with in fact any structure — see Sec. 6). In the rest of the paper we use as an example a Marketplace project for online selling and buying. A global view of the application entities is depicted on Figure 1. There are several actors, which communicate with the system. Seller s enter an offer to the system and Buyer s search for interesting offers. Both of them mainly communicate directly with the Computer system — in few cases, they have to communicate through a Clerk who passes information to the Computer system. There is also a Supervisor which maintains the Computer system. A Credit verification agency verifies Seller’s and Buyer’s operations and finally a Trade commission confirms the offers. The use case on Figure 2a is a part of the Marketplace specification (the whole specification has 19 use cases) and it describes a communication between the Buyer (as PA), Clerk (as SuD), and Computer system. It is prepared according the recommendations. 2.2

Domain Model

A domain model describes entities appearing in the designed system. Typically, the domain model is captured as a UML class diagram and consists of three

Automated Generation of Implementation

37

Fig. 1. The Marketplace project entities

(a) Use case example

(b) Domain model

Fig. 2. Marketplace requirements

types of elements: (1) conceptual classes, (2) attributes of conceptual classes, and (3) associations among conceptual classes. Conceptual classes represent objects used in the system use cases. The attributes are features of the represented objects and associations describe relations among the classes. Figure 2b shows the Marketplace domain model. 2.3

Procasor Tool and Procases

The Procasor [5] is a tool for automated transformation of a natural language (English) use cases into a formal behaviour specification. The transformations are described in [7] and further extended in [3] where almost all restrictions of a use case step syntax were removed. As a formalism into which the natural language use cases are transformed the Procasor uses procases [7] that are a special form of behavior protocols [10]. In addition to procases, a UML state machine diagram is also generated. The procase is a regular-expression-like specification, which can describe an entity behavior as well as the whole system behavior [9]. The procases generate so called traces that represent all possible valid sequences of the actions described by the use cases. Figure 4 shows a procase derived from the use case shown in Figure 2a. A procase is composed of operators (i.e. +, ;), procedure calls ({,}), action tokens, and supporting symbols (i.e. round parenthesis for specifying operators’

38

J. Franc˚ u and P. Hnˇetynka

precedence). Each action token represents a single action that has to be performed and its notation is composed of several parts. First, there is a single character representing a type of the action. The possible types are ? resp. ! for request receiving resp. sending action, # for internal actions (unobservable by others than SuD) and % for special actions. The action type is followed by the entity name on which the action is performed. Finally, the name of the action itself is the last part (separated by a dot). In a case, the entity name is omitted, the action is internal. For example, ?B.submitSelectOffer is the submitSelectOffer action where SuD waits for a request from the B (Buyer) entity. The procases use the same set of operation as regular expressions. These are: * for iteration, ; for sequencing, and + for alternatives. In this paper, we call the alternative operator as a branch action, its operands (actions) as branches, and the iteration operator with its operand as a loop action. A special action is NULL which means no activity and is used in places where is no activity but the procase syntax requires an action specified (e.g. with the alternative operator). Another special action is the first action inside a not main scenario branch, which is called condition branch label and express the condition under which the branch is triggered. Procedure calls (written as curly brackets) represent a behavior (mostly composed of inner actions) of the request receive action after which they are placed (the action is called trigger action). 2.4

Goals Revisited

As described in the sections above, the Procasor tool parses the use cases written in a natural language and generates a formal specification of behavior of the designed system. A straightforward idea is then why to stop just with the generated behavior description and not to generate also an implementation of the system which implements the work-flow captured in the use cases. The goal of this paper is to present an extension of the Procasor tool that based on the use cases generates an executable implementation of the designed system.

3

Generating Process

The development process with our generating tool is as follows. First, requirement engineers collect all requirements and describe them in the form of use cases. Then the Procasor tool automatically generates procases. In parallel, the requirement engineers create a project domain model. As a next step of validating the use cases, the generated procases can be reviewed. Then, our generator is employed and produces an implementation of the developed system. The generated implementation consists of three main parts: (i) use case objects where work-flow captured in a use case is generated, (ii) pages which are used to communicate with users of the system, and (iii) entity data objects which correspond with manipulated objects.

Automated Generation of Implementation

39

Fig. 3. Generator employment

The generated implementation is only an initial draft and serves primarily for testing the use cases and domain model. But it can be also used as a skeleton for the actual implementation and/or to allow customers can gain first impressions of the application. The whole process is illustrated on Figure 3. At this point a single common mistake have to be emphasized (which is also emphasized in [6]). The system requirements cannot be understood as final and unchangeable. Especially in incremental development, the requirements are created in several iterations and obviously the first versions are incomplete. Therefore if the generator is used on such use cases, it can generate completely wrong implementation. But this implementation can be used to validate the use case, repair them and regenerate the implementation.

4

Generating Tool in Detail

The generator of the implementation takes as an input the procases generated by the Procasor and the created domain model of the designed system. From these inputs, it generates the executable implementation. The generation is automated and it consists of three steps: 1. First, procases generated from the Procasor are rearranged into a form, in which still follow the Procase syntax but are more suitable for generating the implementation (Sec. 4.1). 2. Then, a relation between words used in the use cases and elements in the domain model is obtained and parameters (i.e. their numbers and types) of the methods are identified (Sec. 4.2). 3. Finally, the implementation of the designed system is generated (Sec. 4.3). 4.1

Procase Preprocessing

The procases produced by the Procasor do not contain procedure calls brackets (see 2.3), which are crucial for successful transformation of the procases into the code. Except several marginal cases, each use case is a request-response sequence between SuD and PA (for enterprise applications). In the procase, a single

40

J. Franc˚ u and P. Hnˇetynka

request-response element is represented as a sequence of actions from which the first one is the request receive action (i.e. starts with ?) and then followed by zero or more other actions (i.e. sending request action, internal actions, etc.). In other words, SuD receives the request action, then performs a list of other actions, and finally returns the result (i.e. end of the initial request receive action). Hence, the sequence of actions after the request receive action can be modeled as a procedure content and enclosed in the procedure call brackets. The following example is a simple procase in a form produced by the Procasor: ?PA.a; #b; !SA.c; ?PA.d; #e; #f. After identifying the procedure calls, the procase is modified into the following form: ?PA.a{#b; !SA.c};?PA.d{#e; #f}. At the end, the code generated from this procase consists of two procedures — first one generated from the ?PA.a action and internally calling the procedures resulted from #b and !SA.c, and the second one generated from ?PA.d and calling #e and #f. The approach described in the paragraph above works fine except for several cases. In particular, these are: (1) first action of the use case is not a request receive action, (2) a request receive action is in a branch(es), and (3) a request receive action is anywhere inside a loop. In a case the first action of the use case is not a request receive action, a special action INIT is prepended to the use case and the action till the first request receive action are enclosed in the procedure call brackets. In the generated code, a procedure generated from the INIT action is called automatically before the other actions. Two other cases cannot be solved directly and require more complex preprocessing. To solve these cases, we enhance procases with so called conditional events, which allow to “cut” branches of the procase and arrange them in a sequence, but which do not modify the procase syntax. The conditional events allow to mark branches of the alternatives by a boolean variable (written in the procase just as a name without any prefix symbol followed by a colon, e.g. D:). Such a mark modifies the behavior of the procase in a way that only the traces which contain the action with a declaration of the variable (to true) continue with this marked branch. When the value of the variable is false, the traces continue with the unmarked branches. Variables can be set to true via the action written as the variable name prefixed with the $ symbol (e.g. $D) or to false by its name with the $ and ∼ symbols (e.g. ∼$D). At the beginning of each procase, all variables are undeclared. Branch transformation. First, we sketch how to rearrange a procase with the request receive action placed in a branch. The general approach of identifying procedures as described above does not work as it would result in nested procedures. To avoid them, it is necessary to rearrange the procase in order to place affected branches sequentially. The rearrangement in a basic form is described as follows. Actions belonging to subsequent actions of the processing request receive action are cut out and wrapped into new procedure call. The new procedure call is put into new branch action beside NULL and marked with new conditional event variable.

Automated Generation of Implementation

41

Fig. 4. Procase example before and after Preprocessing

The new conditional event variable declaration is appended on previous place of the request receive action. Figure 4 shows procase before and after Preprocessing transformation. The processed procase is completely equivalent to the former one (they generate the same set of traces) and does not contain the problematic branch. Loop transformation. The transformation of the procases with the request receive action located in a loop action is quite similar to the previous case. Again, the transformation guarantees that the resulting procase generates the same traces as the original one. The following procase is an example with the request receive action inside the loop: ?PA.a;#b;(#c;?PA.d;#e)*#f — and the resulting transformed procase: ?PA.a {#b; (#c; $D + #f )}; (D: ?PA.d {#e; (#c + #f; ∼$D)} + NULL)*. Unresolved cases. In a case the request receive action is located in two or more nested loops or in a loop nested in branches, the previous two transformations do not work. The procase is then marked as unresolved, excluded from the further processing and has to be managed manually. On the other hand, such use cases are very unreadable (see [6] for suggestions about avoiding the nested branches and loops) and therefore the skipped use cases are candidates for rewriting in a more simple and readable way. 4.2

Determining Arguments

Once the procases have been preprocessed into sequences of actions grouped as procedure calls, the next step is to determine arguments of the identified procedures, types of the arguments, and how their values are assigned. The arguments are subsequently used as arguments for methods in the final generated code. As mentioned in [6], noun phrases appearing in the use cases are tied to the domain model elements labels and this connection is used in our approach for identifying the arguments. The process of determining arguments is as follows.

42

J. Franc˚ u and P. Hnˇetynka

The noun phrases which may refer to the data manipulated in the use case step are extracted by the Procasor from the use case step sentence. The list of extracted words is matched against keywords of the domain model (by the keywords we mean names of the classes, attributes, and associations). There are many options to match the keywords — currently in our implementation we use a simple case-insensitive equality of strings. The determined types are compared with arguments of previous procedures (if exist) and the already used arguments are copied (their values). If the previous procedures are located in a branch parallel with the NULL action they are excluded from processing as they may not be called before the processed one. Now, the process behaves differently based on a type of the entity, on which the action is called. The types are (1) human user entities (UE) such as buyer, seller, etc. and (2) parts of the system or other computer systems (SE). For the trigger action and actions with UE SuD, the unmatched determined types are used as arguments (i.e. parameters which have to be inputted by users). For actions with SE SuD the unmatched determined types are also added as arguments but with default values (during the development of the final application, developers have to provide correct values for them). 4.3

Application Generation

Generation of the final application employs multiple commonly used design patterns. Based on these patterns, the generated code is structured into three layers — presentation layer, middle (business) layer, and data layer. In the following text, we refer to objects of the presentation layer as pages because the most commonly used presentation layer in contemporary large applications employs web pages but any type of the user interface can be generated in the same way. The middle layer consists of so called use case objects which contain the business logic of the application. Also, the middle layer contains entity objects where the internal logic (implementation of the basic actions) is generated (the use case objects implement the ordering of the actions and call the entity objects). We do not describe generation of the data layer, as it is well captured in common UML tools and frameworks (generation of classes from class diagrams etc. — see Sec. 5). The generation depends on the type of entity — pages are generated for UE while for SE only non-interactive code. Thus, a page is generated for every action performed by UE (procedure call triggering actions and procedure call internal actions). If the use case has SuD as UE then elements generated from the internal actions of a procedure call are named with the suffix “X” to allow their easier identification during future development as in most cases they have to be modified. Based on a combination of communicating actors, the generation distinguishes four cases how the code is generated from a procedure call. (i) If PA and/or SA is UE, then a page is generated for every procedure call, which is triggered by this UE. Otherwise (i.e. PA/SA is SE), (ii) an action

Automated Generation of Implementation

43

Fig. 5. Generated elements

implementation method is generated in the actor entity object and the action method body contains a call to the corresponding use case object. (iii) If SuD is UE, then a method in the corresponding use case object is generated for each procedure call of SuD. The method body calls the actor entity object and redirects to “X” pages, which manage the internal procedure call actions. Internal procedure call actions are generated in a similar way to the request receive action with UE PA — the “X” page and a method inside the “X” use case object are generated. The method inside the “X” use case object is generated as a simple delegation method to the corresponding entity object and redirection to the particular page. And finally (iv) if SuD is SE, then inside the corresponding use case object, a method with the body containing the internal procedure call actions is generated. Figure 5 shows the procase of the Buyer-buys-selected-offer use case and generated elements of this use case. The following sections describe each type of the generated objects in more details. Pages. As generated, pages are intended for testing the use cases and are expected to be reimplemented during the further development. A single page is generated for each action interacting with UE. In a case of UE PA there is a page for every triggering action and in addition for UE SuD there is also a page for every procedure call internal action. If the action has arguments which can be inputted then for each of them an input field is generated. Values are assigned by humans during testing the generated system. For the UE PA actions, the corresponding pages have a button (an input control element) that allows to continue to the next page i.e. to continue in the use case (there is only a single button as there is no other choice to continue).

44

J. Franc˚ u and P. Hnˇetynka

On the pages belonging to the UE SuD actions, there are several buttons, which reflect the possibilities of continuation in the original use case. For a sequence of the actions, the page contains the “continue” button; if the next action is a branch action then the page contains a button for each branch (the default button is for the main scenario branch — the buttons for the rest of the branches are labeled by the branch condition label; if the next action is a loop action then the page has a button to enter the loop and another button to skip the loop (following definition of loop operation). Use Case Objects. The use case objects contain the business logic (workflow) of the use case, i.e an order of actions in the main scenario and all possible branches. Bodies of the generated methods differ according to SuD. UE SuD: As described above, a method in the corresponding use case object is generated for each procedure call of UE SuD. For each trigger action, the method body contains a call to the particular entity object and redirection to a page of the subsequent action. For internal procedure call actions, a similar method body is created in “X” use case object. SE SuD: A body of the method generated for the procedure call trigger action from the use case with the SE SuD contains the internal procedure calls. For the SuD internal actions, methods are called on the use case SuD entity object and for request send actions, methods are called on the action triggered entity objects. The branch actions are generated as a sequence of the condition statements (i.e. if () ... else if () ...) with as many elements as branches in the branch action. In each if statement a particular actions are generated while the last else statement contains the main scenario actions. A similar construction but with a loop statement (while) is created for the loop action. The number of iteration in the loop statement and choice of the particular branch in the condition statements cannot be determined from the use case. Therefore, the statements are generated with predefined but configurable constants inside the use case object. Entity Data Objects. The internal logic of actions is not captured by the use cases neither by the domain model. Therefore, the entity objects are generated with almost empty methods containing only calls to a logger and they have to be finished by developers. For testing purposes, the logging methods seem to be the most suitable ones as designers can immediately check the traces of the generated system. 4.4

Navigation

Navigation (transitions) between the pages is an important part of the application internal logic as it determines the order of procedure calls and sequence of actions. The navigation is derived from the procases as a set of navigation rules. The pages/objects have associated these rules that contain under which circumstances which transition has to be chosen.

Automated Generation of Implementation

45

In general, the navigation rules are created from special actions that can change transitions (aborts, etc.), branch actions, and loops. In a case of the use case with SE SuD, the rules are applied to determine transitions between calls of the actions. In a case of UE SuD, the rules determine how the pages are generated, i.e. which buttons are placed on them. 4.5

Implementation Details

To prove our approach is feasible, we have implemented the proposed generator. As a particular technology in which applications are generated, we chose the Java EE platform with Enterprise Java Beans as business layer and Java Server Faces as presentation layer. The generator itself has been written in plain Java. The generator generates sources together with an Ant build file, which can immediately compile and deploy the application to the JBoss application server, which allows users to inspect and modify code and iteratively test the application. Based on the chosen technologies and used design patterns the first two application layers are mapped into the following five tiers. The pages resulted in two tiers: (i) JSF pages and (ii) backing beans. The middle layer then results into tree tiers: (iii) business delegator tier, (iv) Enterprise Java Bean tier, and finally (v) manager tier. Generation of the data persistence layer is not currently supported but it is a simple task, which will be added soon (see Sec. 6).

5

Evaluation and Related Work

To verify our generator, we used it on the Marketplace application (see Sec. 2.1). The generated implementation was compiled and directly deployed to an application server. The implementation consists of approx. 70 classes with 13 EJBs. The complete application has 92 action, from which only 16 actions were generated with wrong arguments and had to be repaired manually (we are working on an enhanced method of argument detection — see Sec. 6). Testing of the generated application discovered a necessity to add one use case, two missing extensions in another use case, and also suggested restructuring other two use cases. All these defects also could be detected directly from the use cases but with generated application, they became evident immediately. Our tool can be also viewed as an ideal application of the Model-driven Architectures (MDA) [8] approach. In this view, the uses cases and domain model serve as a platform independent model, which via several transformations are transformed directly into an executable code, i.e. platform specific model. Currently, the existing tools usually generate just data structures (source code files, database tables, or XML descriptors) from the UML class diagrams but no interaction between entities (i.e. they handle just the class diagrams) and as far as we know, there is no tool/project that generates the implementation from the description in a natural language. Below, there are several projects or tools that take as an input not only class diagrams but still they work with diagrams and not with a natural language.

46

J. Franc˚ u and P. Hnˇetynka

The AndroMDA [1] is the generator framework which transforms the UML models into an implementation. It supports transformations into several technologies and it is possible to add new transformations. In general, it works with the class diagrams and based on the class stereotypes, it generates the source code. Moreover, it can be extended to work with other diagram types. A similar generator (made as an Eclipse extension) is openArchitectureWare [11], which is a general model-to-model transformation framework. In [12], the sequence diagrams together with class diagram are used to generate fragments of code in a language similar to Java. The generation is based on the order of messages captured in the sequence diagram and the structure of the class diagram. There is also a proposed algorithm for checking consistency between these two types of diagrams. Similarly in [4], Java code fragments are generated from the collaboration and class diagrams. The authors use enhanced collaboration diagrams in order to allow better management of variables in the generated code. In [13], the use cases are automatically parsed and together with a domain model are used to produce a state transition machine, which reflects behavior of the system. From the high level view, the used approach is very similar to our solution but they allow to process only very restricted use cases and thus the approach is quite limited.

6

Conclusion and Future Work

The approach proposed in the paper allows for automated generation of executable code directly from a requirements specification written as use cases in a natural language. Also, we have developed a prototype, which generates JEE applications via the proposed approach. Applications generated by our tool are immediately ready to be deployed and launched and they are suitable for testing the use cases (i.e. if the requirement specification is complete and well structured) and as a starting point for the development of the real implementation. The proposed generator has several shortcomings, which suit for further improvements. An important issue is connected with associations among the classes in the domain model. The current implementation correctly handles just one-toone associations. The one-to-many or many-to-many associations result in the code of an application to arrays and therefore the determination of the arguments is more complex. We plan to solve association limitation by analysis of sentence to determine whether a method argument is the array or object itself. Also, we plan to add a categorization of verbs to allow better management of arguments of the procedures. Finally, we plan to add the generation of a data layer to the application. The required structure of the use cases (based on recommendations in [2]) can be seen as another limitation but we already have an approach, which allows processing of use cases with almost any structure (see [3]) and we are incorporating it to the implementation.

Automated Generation of Implementation

47

Acknowledgements The authors would like to thank Vladimir Mencl and Jiri Adamek for valuable comments. This work was partially supported by the Grant Agency of the Czech Republic project 201/06/0770.

References 1. AndroMDA, http://galaxy.andromda.org 2. Cockburn, A.: Writing Effective Use Cases, 1st edn. Addison-Wesley, Reading (2000) 3. Drazan, J., Mencl, V.: Improved Processing of Textual Use Cases: Deriving Behavior Specifications. In: van Leeuwen, J., Italiano, G.F., van der Hoek, W., Meinel, C., Sack, H., Pl´ aˇsil, F. (eds.) SOFSEM 2007. LNCS, vol. 4362, pp. 856–868. Springer, Heidelberg (2007) 4. Engels, G.: UML collaboration diagrams and their transformation to java. In: France, R.B. (ed.) UML 1999. LNCS, vol. 1723, pp. 473–488. Springer, Heidelberg (1999) 5. Fiedler, M., Francu, J., Mencl, V., Ondrusek, J., Plsek, A.: Procasor Environment: Interactive Environment for Requirement Specification, http://dsrg.mff.cuni.cz/~ mencl/procasor-env 6. Larman, C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd edn. Prentice Hall PTR, Upper Saddle River (2001) 7. Mencl, V.: Deriving Behavior Specifications from Textual Use Cases. In: Proc. of WITSE 2004, Linz, Austria (September 2004) 8. OMG: Model Driven Architecture (MDA), OMG document ormsc/01-07-01 (July 2001) 9. Plasil, F., Mencl, V.: Getting ”Whole Picture” Behavior in a Use Case Model. In: Proceedings of IDPT, Austin, Texas, U.S.A. (December 2003) 10. Plasil, F., Visnovsky, S.: Behavior Protocols for Software Components. IEEE Transactions on Software Engineering 28(11) (November 2002) 11. openArchitectureWare, http://www.openarchitectureware.org 12. Quan, L., Zhiming, L., Xiaoshan, L., Jifeng, H.: Consistent Code Generation from UML Models, UNU-IIST Rep. No. 319, The United Nations University (April 2005) 13. Som´e, S.S.: Supporting Use Cases based Requirements Engineering. Information and Software Technology 48(1), 43–58 (2006)

Enhancing Use Cases with Screen Designs Łukasz Olek, Jerzy Nawrocki, and Mirosław Ochodek Poznań University of Technology, Institute of Computing Science, ul. Piotrowo 3A, 60-965 Poznań, Poland {Lukasz.Olek,Miroslaw.Ochodek}@cs.put.poznan.pl

Abstract. This paper presents a language called ScreenSpec that can be used to specify screens at requirements elicitation phase. ScreenSpec was successfully applied in 8 real projects. It is very effective: average time needed to specify a screen is 2 minutes, and takes an hour to become proficient in using it. Visual representation generated from ScreenSpec can be attached to requirements specification (e.g. as adornments to use cases). Keywords: Use cases, GUI Design, Prototyping, ScreenSpec.

1

Introduction

Use cases are the most popular way of specifying functional requirements. A survey published in IEEE Software in 2003 [12] shows that over 50% of software projects elicit requirements as use cases. Use case is a good way of describing interaction between a user and a system at a high level, so maybe now the number can be even higher. At the same time many practitioners (in about 40% of projects [12]) draw user interfaces to visualise better how the future system will behave. This is wise, since showing user interface designs (e.g. prototypes [14,17,8,18], storyboards [10]) together with use cases helps to detect more problems with requirements ([13]1 ). Unfortunately, user interface details would clutter use-case description and should be kept apart from the steps ([6,7]), but they can be attached to use cases as adornments [6]. Much have been said about writing use cases [6,7,16,11,9] (e.g. how to divide them into main scenario and extensions, what type of language to use), however it is not clear how to specify UI details as adornments. Practitioners seem to either draw screens in graphical editors and attach graphical files to use cases, or just describe it using a natural language. Both approaches have advantages and disadvantages. The graphical approach is easier to analyse by humans, however more difficult to prepare and maintain. On the other hand, the textual approach is much easier to prepare, but not so easy to perceive. The goal of this paper is to propose a simple formalism called ScreenSpec to specify user interface details. It has both advantages of the approaches mentioned  1

This research has been financially supported by the Polish Ministry of Science and Higher Education grant N516 001 31/0269. See experiment conclusions in section: “Mockup helps to unveil usability problems”.

Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 48–61, 2011. c IFIP International Federation for Information Processing 2011 

Enhancing Use Cases with Screen Designs

49

earlier: it is inexpensive to prepare and maintain, and can be automatically converted to a graphical form (attached to use cases as adornments can stimulate readers visually). Currently the language is limited to describe user interfaces of web applications. It is easy to propose a new formalism, but it is much more difficult to prove that it is useful. ScreenSpec has been successfully used in 8 real projects. An investigation was carried out to find out how much effort is needed to use ScreenSpec, and how much time does it take to learn how to use it. The plan of this paper is following. Section 2. describes some approaches to UI specification that are popular in software engineering. Section 3. describes the ScreenSpec language. Section 4. describes case studies that were conducted to check whether ScreenSpec is complete enough and flexible to specify real applications and how much effort does it take to specify screens at requirements elicitation phase. Section 5. describes a way to generate graphical files representing particular screens from ScreenSpec. Section 6. presents how the visual representation of screens can be embedded in requirements documents: as adornments, or as a mockup. The whole paper is concluded in Section 7.

2

Related Work

There are many outstanding technologies and formalisms used to describe user interface. One of them is XUL[2] (XML User Interface Language) from the Mozilla Foundation. This is an interesting language used to describe platformindependent user interface. It has many interesting features, e.g. separation of presentation from application logic, easy customisation, localisation or branding. However this language seems to be too much implementation-oriented, to be used at requirements elicitation phase. There are two important impediments to use XUL for this purpose. Firstly, one has to know component type before it can be specified (e.g. ).Therefore it is not possible to start from specifying the structure of information connected with particular screen, and then add details about control types (see Section 3.3). Secondly, labels for components have to be defined explicitly. This means that for each component two declarations are required: one for a label, and second one for a control. However it would be interesting to generate (or round-trip-generate) XUL from ScreenSpec. Produced XUL could be easily used for implementation. There are other technologies that are getting more and more popular nowadays, like for instance, MDSD (Model Driven Software Development) approaches, that provide an ability to generate a whole application from a set of models (e.g. WebML[3], UWE/ArgoUWE[5]). Unfortunately this approach still seems to require too much effort, to be successfully used at the requirements elicitation phase. There are companies using such approach, that Poznań University of Technology cooperates with. According to their experience it takes at least several hours to describe a single use case with MDSD models. It is definitely to long to be used at requirements elicitation phase, so they use generic text editors to specify use cases and screens.

50

3

Ł. Olek, J. Nawrocki, and M. Ochodek

ScreenSpec - Language for Screen Specification

The goal of the ScreenSpec language is to allow analyst to specify the structure of user interface very efficiently. Since this approach is supposed to be used at early stages of requirements elicitation phase, it would be wise to focus on the structure of screens and information exchanged between a user and a system, rather then on such attributes like colours, fonts, layout of components. This is called a lo-fidelity approach([19,15]) and is used in ScreenSpec. It is best to explain how ScreenSpec specification looks like on a simple example. Let us imagine an Internet shop with a view of all categories (see Fig. 1). It contains a list of categories (each of them is represented by a link with its name) and lists of subcategories. There are also some links to other shopping-views (by brand, by store, etc). 3.1

Language Definition

Screens. Each screen is specified with a set of lines that describe its structure. The definition starts with keyword SCREEN followed by screen’s identifier (each screen must have an unique ID). The following lines are indented and describe components, that belong to the screen: SCREEN Screen_ID: Component_definition_1 Component_definition_2 ...

Where Component_definition_n is a definition of a basic component or a group. Basic components. Basic components are mainly simple widgets taken from the HTML language. They are specified using the following syntax:

SCREEN Shop_By_Category: Categories(LIST): Name(LINK) Subcategories(LIST): Name(LINK) Shop_by_Brand(LINK) Shop_by_Store(LINK)

Fig. 1. A screen showing a list of categories (screenshot taken from shopping.yahoo.com), and its corresponding specification in ScreenSpec

Enhancing Use Cases with Screen Designs

51

Component_ID[(CONTROL_TYPE)]

where: – Component_ID is a string that identifies the component, e.g. Login_name, Password, Author. It has to be unique in the scope of the screen or parent group. – CONTROL_TYPE is one of: BUTTON, LINK, IMAGE, STATIC_TEXT,DYNAMIC_TEXT, EDIT_BOX, COMBO_BOX, RADIO_BUTTON, LIST_BOX, CHECK_BOX, CUSTOM. This parameter is optional (EDIT_BOX by default) and can be defined by an analyst later (see Section 3.3). Three controls do not come from a standard set of HTML controls, thus require additional comment: (1)STATIC_TEXT is used to display a text that will be the same on each screen instance (e.g. a comment or instructions) (2)DYNAMIC_TEXT is a block of text generated dynamically by the system (e.g. a total value of an invoice) and (3)CUSTOM is used to represent non-standard components (e.g. date picker). Groups. Groups of components are containers for widgets, usually providing additional features. They are defined using the following syntax: Group_ID[(GROUP_TYPE)]: Component_definition_1 Component_definition_2 ...

where: – Group_ID is a string that identifies the group. – Component_definition_n - is a definition of a basic component or another group of components – GROUP_TYPE - determines the type of the group: • SIMPLE or omitted - such group is just used to introduce structure to the screen, but it does not provide any additional semantics to its components • LIST - its components are repeated in a list, all child components form a single list item • TABLE - its components are repeated in rows, as a table (similar to LIST, but different layout) • TREE - similar to list, but its items can also contain another lists of the same structure (e.g. used to create tree of categories, or site map tree). 3.2

ScreenSpec Advanced Elements

Static values are used to specify, that the component will have the same values on each screen. For example, when we have a combo box that allows to choose sex of user, it would always have two values: “Male” and “Female”. We can express such case in ScreenSpec using the following structure:

52

Ł. Olek, J. Nawrocki, and M. Ochodek

Component_ID(...):Value_1|Value_2|...

e.g. Sex(COMBO_BOX):Male|Female Template mechanism can be used to build more complex screens. Two elements are needed to do this: a template definition and a reference to the template in the particular screen. This can be done using the following structure (shown in the example): TEMPLATE Main: Header: Sign_in(LINK) Register(LINK) ... Contents(CUSTOM) ... SCREEN All_categories(Main): ...

Each template is defined with keyword TEMPLATE followed by a template name. The structure of template is the same as the structure of a screen. The main difference is that it requires putting the additional component Contents(CUSTOM) - which is a placeholder for the specific screen which will use the template. When screen is supposed to use a particular template, we need to mention the name of the template in parenthesis, e.g. SCREEN All_Categories(Main). Include common screen elements. When there are the same controls (functional blocks) used in more screens it would be wise to declare them once and then make references. We can do this by using INCLUDE keyword: SCREEN Search_box: ... SCREEN Search_results: INCLUDE Search_box Results(LIST): ...

Select clause. It is common that a screen has different variants depending on situation. For example, a screen can display a list of all accepted papers or a message that no papers are accepted yet. When one of several variants can be used, it is specified by a select clause: SELECT: Component_definition_1 Component_definition_2

This means that either Component_definition_1 or Component_definition_2 will be displayed on a real screen. More than two variants are possible (additional lines should be added within the SELECT clause). Components, that are specified here can be both simple components, or groups.

Enhancing Use Cases with Screen Designs

3.3

53

Iterative Approach to Screen Specification

ScreenSpec is designed to be used by an analyst at requirements elicitation phase. This phase is exploratory, which means that change-involving decisions are made frequently. It would be important to provide incremental approach to the screen specification process. It would be great if analyst could just roughly describe screen at the beginning (only the structure of information), and add more details later (when a customer confirms it is correct). Therefore ScreenSpec has 3 levels of details: L1 Component names - need to be specified at the beginning. L2 Types of controls and groups - specifies types of information connected with each screen. L3 Static values and templates. These levels can be mixed throughout the specification process: some fragments of screens can be written at one level of details, whereas other ones at another level.

4

Experience with ScreenSpec

4.1

Specifying Screens for the Real Projects – Case Studies

Analysts usually use word processors and sheets of papers to author requirements. Keeping it in mind, it seems that introducing formalised requirements models can be risky. It may happen that some of the developed-system features might be too difficult to describe. To make sure that the ScreenSpec formalism is complete and flexible enough to be used for describing real systems, eight case studies were conducted. They included a large variety of projects. Some of them were internally-complex (large number of sub-function2 requirements), with a small amount of interaction with a user (e.g. Project A, Project C). Others were interaction-oriented, with a great number of use cases and screens (e.g. Project D, Project G). First 6 projects were selected from the Software Development Studio course at Poznań University of Technology. These projects were developed for external customers by students of the Master of Science in Software Engineering. Students were successfully using ScreenSpec approach to specify screens. They also raised some minor suggestions for ScreenSpec language, and small simplifications were introduced afterwords. Then screens for two commercial projects were also written using ScreenSpec language. In both cases all screens were successfully specified. It seems that number of lines of code (LOC) per screen may differ depending on the screen complexity. In analysed projects average LOC per Screen varies from 3.0 to 14.5 (see table 1). 2

After Cockburn[7]: a sub-function requirement is a requirement that is below the main level of interest to the user, i.e. “logging in”, “locate a device in a DB”.

54

Ł. Olek, J. Nawrocki, and M. Ochodek Table 1. Eight projects selected for the case study

4.2

Screens

Average LOC/Screen

Total LOC

4

2

4

14.5

58

2

5

9.4

47

Project

Business

Subfunctional

ScreenSpec Screens

User

Number of Use Cases

Project A

0

Project B

3

13

Project C

0

5

0

4

3

12

Project D

0

16

0

27

4.7

128

Project E

0

4

0

7

3.9

27

Project F

1

3

2

3

13

39

Project G

0

44

39

92

9.5

917

Project H

2

12

0

7

5.1

36

ScreenSpec Efficiency Analysis

Although an average amount of code required to specify a screen with ScreenSpec seems to be rather small, two important questions arise: – Q1: how much effort is required to specify3 a screen? – Q2: how much time is required to learn how to use ScreenSpec? The second question is also important because practitioners tend to choose solutions, which provide business value and are inexpensive to introduce. If an extensive training is required in order to use ScreenSpec efficiently, there might be a serious threat, that the language will not be attractive to the potential users. In order to answer these questions, a controlled case study was conducted4 . Eight participants were asked to specify sequence of 12 screens coming from the real application (provided as the series of application screenshots). The time required for coding each of the screens was precisely measured (up to the seconds). The code was written manually on sheets of paper. Participants were also asked to copy a sample screen specification, in order to examine their writing speed. Before they started to specify screens, they had been also introduced to the ScreenSpec during the 15-minute lecture, and each of them was also provided with a page containing the ScreenSpec specification in a nutshell. All materials provided to participants are published at [1]. 3 4

The term "specifying" is understood here as the process of transcribing the vision of the screen into the ScreenSpec code. The case study is labeled here as a controlled, because the methodology was similar to that used in case of controlled experiments, however the nature of questions being investigated refers rather to the "common sense", then to some obtainable values (e.g. compare average learning time, to the one which is acceptable for the industry).

Enhancing Use Cases with Screen Designs

55

Table 2. Effort and lines of code for each participant and task (sample screen refers to the task measuring participants writing speed)

Time [min] Sample Participant Screen P1 P2 P3 P4 P5 P6 P7 P8 Mean SD

0.9 1.6 1.2 1.3 1.0 1.0 1.0 1.6 1.2 0.3

1

2

3

5

6

7

8

9

11

12

4.3 2.8 1.8 1.7 2.4 2.5 1.9 5.4 2.9 1.3

2.0 2.0 2.0 1.4 2.2 1.6 1.5 4.2 2.1 0.9

2.0 3.6 3.0 5.7 1.0 1.5 1.6 3.2 2.7 1.5

6.2 3.6 4.6 2.5 2.5 3.7 2.0 5.8 3.9 1.6

2.3 1.2 1.5 1.8 1.4 1.3 1.1 3.7 1.8 0.9

4.7 2.0 2.4 1.9 1.8 1.4 1.3 2.5 2.3 1.1

7.7 4.1 6.2 3.3 3.6 4.1 2.3 4.7 4.5 1.7

3.3 3.1 4.8 3.5 4.3 3.0 1.8 5.6 3.7 1.2

5.5 3.1 3.9 4.7 3.0 3.3 3.2 4.0 3.8 0.9

6.3 4.2 4.4 3.9 4.2 3.8 3.5 6.7 4.6 1.2

8

9

11

12

Lines of code - LOC Sample Participant 1 Screen 8 P1 14 8 P2 9 8 8 P3 8 P4 7 8 P5 11 8 P6 9 8 10 P7 8 P8 5 8.0 9.1 Mean SD 0.0 2.7

2 6 7 6 6 8 7 7 7 6.8 0.7

3

5

6

8 17 7 9 12 6 9 10 6 9 10 6 8 11 6 8 9 7 9 10 6 7 10 6 8.4 11.1 6.3 0.7 2.5 0.5

7

20 35 20 25 32 8 21 16 18 19 7 22 16 18 25 7 15 17 20 19 8 16 16 15 23 8 17 14 17 23 7 17 15 21 21 7 14 16 13 18 9.0 19.6 16.3 18.4 22.5 4.5 6.8 1.8 3.7 4.5

Descriptive analysis and data clearing. During the completion of each task (single screen specification) two values were measured: – time required to finish the task – lines of code developed to specify the screen Screens specifications, developed by participants, differed in respect to their size, because they were specified only on the basis of the screenshots, which were be perceived slightly differently by different people. What is more, some of the ScreenSpec structures might be used optionally. The detailed results of the case study is presented in table 2. Before proceeding to the further analysis results for all tasks were carefully analysed in order to find potential outliers. The task was marked as a suspicious if the variability in lines of code provided by participants was high (or there were outlying observations). According to the box plots presented in figure 2 tasks 1, 4, 5, 7, 8, 9, 10, 11, 12 were chosen for further investigation in order to find out the reasons for the LOC variability. It turned out that tasks 4 and 8 were ambiguous, because in both cases there were two possible interpretations of the screens semantic. What is more, the amount of code required to specify each of two versions differed significantly. Therefore those tasks were excluded from the further analysis.

Ł. Olek, J. Nawrocki, and M. Ochodek

a)

b)

8

36

7,2

32

Size [LOC]

5,6 4,8 4 3,2

28 24 20 16 12 8

2,4

Task (screen)

12

11

9

10

8

7

6

5

4

12

11

9

10

8

7

6

5

4

3

2

1

0

3

4

1,6

2

Time [min]

6,4

1

56

Task (screen)

Fig. 2. Effort and size of code (LOC) variability for each task, a) box plot presents effort variability for each task, b) box plot presents lines of code variability for each task

Productivity analysis. Based on the effort and code size measured for each task performed by each participant, a productivity factor can be derived. It will be defined here as a time required to produce a single line of code. It might be calculated using equation 1. P ROD =

Ef f ort Size

(1)

Where: – P ROD - is a productivity factor understood as a number of minutes required to develop a single line of code – Ef f ort - is an effort required to complete the task (measured in minutes) – Size - is the size of code developed to specify the screen (measured in LOC) Effort measured during the case study consists of two components: (1)time required for thinking and (2)writing down the screen. It would be difficult to precisely measure both of them, however knowing the writing speed of each participant (see equation 2) it is possible to calculate the approximate effort spent only on thinking. It can be further used to estimate cognitive productivity factor (see equation 3), which can be understood as a productivity of thinking while coding the screen. It is independent from the tool (effort needed mentally produce the screen-specification code). Vwriting =

Sizesample Ef f ortsample

(2)

Enhancing Use Cases with Screen Designs

57

Where: – Vwriting - is a writing speed (measured in LOC per minutes) – Ef f ortsample - is an effort required to copy the code for the sample screen (measured in minutes) – Sizesample - is the size of the code for the sample screen – 8 LOC P RODcognitive =

Ef f ort − (Size/Vwriting ) Size

(3)

Where: – P RODcognitive - is an estimation of cognitive productivity factor understood as a number of minutes spend on thinking in order to produce a single line of code – Ef f ort - is an effort required to complete the task (measured in minutes) – Size - is the size of code to specify the screen (measured in LOC) – Vwriting - is a writing speed (measured in LOC per minutes) Cognitive and standard productivity factors were calculated for each task performed by participants. The chart presenting mean values for each task is presented in figure 3.

Productivity [min/LOC]

0.40 0.35 0.30 0.25

Mean productivity factor

0.20 0.15

Mean cognitive productivity factor

0.10 0.05 0.00 1

2

3

5

6

7

9

10

11

12

Task (screen) Fig. 3. Mean (cognitive and standard) productivity factors for each task (screen)

Q1: how much effort is required to specify a screen? If the mean productivities from the first and the last task are compared, it would mean that average beginner produces around 2.81 LOC / minute while person with some experience 4.7 LOC / minute (this of course may very depending on the screen complexity). That means that total effort of specifying all of the screens for the largest project included in the case studies – Project G (92 screens with total of 917 LOC of screen specifications) would vary from 3.2 to 5.4 hours depending on analyst skill. What is more, an average screen size is around 8 LOC (average

58

Ł. Olek, J. Nawrocki, and M. Ochodek

from table 1), which could be specified in less then 2 minutes (for experienced analyst, and less then 3 minutes for beginner). Therefore it seems that the SpecScreen notation might be used directly during the meetings with customer. It is also worth to mention that if there was an efficient editor available (with high usability), the productivity factor for potential user, would be closer to the cognitive one. This means that a 8 LOC screen would be specified in about 30 seconds. Q2: how much time is required to learn how to use ScreenSpec? By looking at the productivity chart presented in figure 3, the learning process can be investigated. The ratio between productivity factors calculated for the ending and beginning task is 1.69. In addition it seems that after completing 8-10 tasks, learning process saturates. Therefore it seems that participating in a single training session which includes a short lecture and ten practical tasks (about an hour), should be enough to start using ScreenSpec effectively. An interesting observation is regarding the task number 5, because the productivity factor suddenly increased at this point (more time required to produce one line of code). This issue was further investigated, and the finding was that the screen for that task contained interactive controls, which appeared for the first time in the training cycle (edit boxes, check boxes etc.). Thus an important suggestion for a preparation of the training course would be to cover all of the components available in the ScreenSpec language.

5

Visual Representation of Screens

ScreenSpec can be authored using a dedicated tool. This is a simple editor, that detects each change, and automatically regenerates graphics files (PNG) that can be attached to requirements documents. The generator uses simple rules to transform ScreenSpec to visual representation: 1. For each component: – EDIT_BOX, COMBO_BOX, LIST_BOX, CUSTOM - a label (equal Component ID) is displayed on the left side of the control, the control’s value is taken from the defined static value, or it is left empty. CUSTOM component is displayed as the EDIT_BOX. – BUTTON, LINK - displays a control with a caption equal to the defined static value, or component ID. – STATIC_TEXT, DYNAMIC_TEXT - displays a piece of text equal the static value or component ID. – RADIO_BUTTON, CHECK_BOX - displays a control followed by a label (label’s value equals the static value or component ID) – IMAGE - displays a label on the left (equal to component ID) and an empty image frame on the right. 2. For each group: – SIMPLE - a header and a frame is created, all children components are placed inside this frame.

Enhancing Use Cases with Screen Designs

59

Fig. 4. An example of visual representation for a LIST group component

– LIST - a header and a frame is created. In the frame 3 rows are displayed (this visualises that a list can have more elements): two rows having the child components, and the third one containing “...” – TABLE - is similar to a LIST, however a new table column is created for each child component. Its label is displayed in the table header rather then on the left (near its control). – TREE - is similar to a LIST, but for each row a nested and smaller list is displayed. Following example (figure 4) shows a visual representation of a simple screen specified in ScreenSpec.

6

ScreenSpec Meets Use Cases

Visual screens generated from ScreenSpec can be directly inserted into requirements specification in adornments section of particular use cases. Having up-todate graphic files allows to update the specification very easily, because many modern text editors allow to link with external files, and update them each time the document is opened (e.g. Microsoft Word, OpenOffice). 6.1

Mockup

Mockup is an interesting artefact created by connecting screens to particular steps of use cases. It is rendered as a simple web application that can display both: use cases and screens at the same time. Use case (displayed on the left side) shows the interaction between an actor and a system (see figure 5). After selecting particular step, an according screen is displayed (on the right side). This artefact seems to be useful in practice, initial feedback from commercial projects using mockups is very positive.

60

Ł. Olek, J. Nawrocki, and M. Ochodek

Actors

Business Processes

Use Cases

Business Objects

UC5: Login to the system Main Scenario: 1. Customer chooses login action . 2. Customer fills in login form . 3. System checks if data is correct and authorizes Customer .

Extensions: 3.A. Customer cannot be authorized 3.A.1. System prints warning info and ask Customer to repeat authorization process . 2.A. There is no account for Customer. 2.A.1. Customer would like to add a new acount to the

Username Password Login Cancel

Fig. 5. An screenshot of Mockup - showing use case with corresponding screens at the same time

It is difficult to connect screens to use case steps in generic text editor, so a dedicated tool called UC Workbench [4] was developed at Poznan University of Technology.

7

Conclusions

User interface designs are often attached to use cases as adornments, because it helps to understand the requirements by IT laymen. However, it is not clear how to specify UI details. This paper proposes a language called ScreenSpec, that can be used for this purpose. ScreenSpec is a formalism that was thoroughly validated. It was used to describe UI in eight real software projects. ScreenSpec allows to work incrementally on screen designs, starting with the general structure of information at particular screen, and then adding more details about widgets. It is very efficient, it takes on average about 2 minutes per screen. ScreenSpec is also easy to learn, it takes about an hour, for a person that has never seen ScreenSpec, to become proficient in using it. Although it is interesting to use ScreenSpec at requirements elicitation stage, it could be even more interesting to use it at later stages. One can think about generating skeleton user interface code (in XUL, SWT, Swing or other technologies), that could be refined during implementation. Appropriate research will be conducted as a future work.

Acknowledgements Authors would like to thank companies which cooperate with Poznań University of Technology: Polsoft and Komputronik. They found time and courage to try our ideas in practice and provided us with a substantial feedback. This research

Enhancing Use Cases with Screen Designs

61

has been financially supported by the Polish Ministry of Science and Higher Education under grant N516 001 31/0269.

References 1. A web page containing all materials for a ScreenSpec evaluation case study, http://www.cs.put.poznan.pl/lolek/homepage/ScreenSpec.html 2. Home page for Mozilla XUL, http://www.mozilla.org/projects/xul/ 3. The Web Modeling Language Home Page, http://www.webml.org/ 4. UC Workbench project homepage, http://ucworkbench.org 5. UWE - UML-based Web Engineering Home Page, http://www.pst.informatik.uni-muenchen.de/projekte/uwe/index.html 6. Adolph, S., Bramble, P., Cockburn, A., Pols, A.: Patterns for Effective Use Cases. Addison-Wesley, Reading (2002) 7. Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, Reading (2001) 8. Constantine, L.L., Lockwood, L.A.D.: Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA (1999) 9. Jacobson, I.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley Longman Publishing Co., Inc., Redwood City (2004) 10. Landay, J.A., Myers, B.A.: Sketching storyboards to illustrate interface behaviors. In: CHI 1996: Conference Companion on Human Factors in Computing Systems, pp. 193–194. ACM Press, New York (1996) 11. Leffingwell, D., Widrig, D.: Managing Software Requirements: A Use Case Approach, 2nd edn. Addison-Wesley Professional, Reading (2003) 12. Neill, C.J., Laplante, P.A.: Requirements Engineering: The State of the Practice. IEEE Software 20(6), 40–45 (2003) 13. Olek, Ł., Nawrocki, J., Michalik, B., Ochodek, M.: Quick prototyping of web applications. In: Madeyski, L., Ochodek, M., Weiss, D., Zendulka, J. (eds.) Software Engineering in Progress, pp. 124–137. NAKOM (2007) 14. Pressman, R.: Software Engineering - A practitioners Approach. McGraw-Hill, New York (2001) 15. Rudd, J., Stern, K., Isensee, S.: Low vs. high-fidelity prototyping debate. Interactions 3(1), 76–85 (1996) 16. Schneider, G., Winters, J.P.: Applying Use Cases: A Practical Guide. AddisonWesley, Reading (1998) 17. Snyder, C.: Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces. Morgan Kaufmann Publishers, San Francisco (2003) 18. Sommerville, Y., Sawyer, P.: Requirements Engineering. A Good Practice Guide. Wiley and Sons, Chichester (1997) 19. Walker, M., Takayama, L., Landay, J.A.: High-Fidelity or Low-Fidelity, Paper or Computer? Choosing Attributes When Testing Web Applications. In: Proceedings of the Human Factors and Ergonomics Society 46th Anuual Meeting, pp. 661–665 (2002)

Mining Design Patterns from Existing Projects Using Static and Run-Time Analysis Michal Dobiš and Ľubomír Majtás Faculty of Informatics and Information Technologies, Slovak University of Technology, Bratislava, Slovakia [email protected], [email protected]

Abstract. Software design patterns are documented best practice solutions that can be applied to recurring problems. The information about used patterns and their placement in the system can be crucial when trying to add a new feature without degradation of its internal quality. In this paper a new method for recognition of given patterns in objectoriented software is presented. It is based on static and semidynamic analysis of intermediate code, which is precised by the run-time analysis. It utilizes own XML based language for the pattern description and the graph theory based approach for the final search. The proof of concept is provided by the tool searching for the patterns in .Net framework intermediate language and presenting the results using common UML-like diagrams, text and tree views. Keywords: Design patterns, reverse engineering.

1

Introduction

It is not easy to develop a good design of a complex system. Experienced designer of object oriented software often rely on usage of design patterns that are known as good solutions to recurring problems. A design pattern can impact scalability of a system and defines the way of modification of the architecture without decreasing its quality. Patterns are based on experience of many software developers and they are abstractions of effective, reliable and robust solutions to repeating problems. A pattern describes a problem, its context and supplies some alternative solutions, each of them consisting of collaborating objects, their methods and services. Introducing patterns to software design provides one more benefit. While class in the object oriented paradigm makes it easier to understand the code by encapsulating the functionality and the data, an instance of a design pattern identifies the basic idea behind the relations between classes. It is an abstract term that can help to understand design decisions made by the original developer. But how to find instances of design patterns in the implemented system, when they represent an idea rather than just an implementation template? A large system has usually long lifetime and original architect of a particular component can leave the team before the system life cycle ends. Modification of the internal Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 62–75, 2011. c IFIP International Federation for Information Processing 2011 

Mining Design Patterns from Existing Projects

63

structure of a software component is a common need during the maintenance or when developing it for a long time. Therefore the precise documentation of design decisions by describing used design patterns becomes necessary. Unfortunately, such documentation is mostly obsolete or absent at all. There can be plenty of design pattern instances in a large system, and each pattern can have many implementation variants. Moreover, a code fragment can play role in more than one pattern. It is unlikely to expect a human being to be able to orientate in a large mesh of connected classes forming a system. Thus, automatic analysis and search have to be done. We focused our effort on analysis of intermediate code produced by compilers of modern object oriented programming languages like C#. This code is also directly executable so its runtime behavior can be inspected as well. With the proposed method and the implemented tool, the valid pattern instances can be found more precisely, so the developers can become familiar with the analyzed system easier and have all the information necessary to make the correct design decisions while modifying it. Besides that, the library of patterns is kept open and new ones can be added using a special editor or by directly editing XML files.

2

Related Work

There are some tools that support reverse engineering with design pattern support, but this feature is far from perfect and there is still research needed to be done. There are three main questions to answer when developing a solid design patterns mining tool. First question that comes out is ”What to find?” It represents the challenge of defining a formal language for the design pattern description that would allow dynamic editing of the catalogue. For humans the most suitable is natural language as it is used in works like the GoF’s catalogue [7]. It is good for description of the pattern’s variability, but is insufficient for the computer processing. UMLbased ”Design Pattern Modeling Language” [9] is visual language consisting of 3 models (specification, instantiation and class diagram) that uses extensions capability of UML but authors propose just the forward engineering way of model transformations. Mathematical logic with its power is introduced in ”LanguagE for Patterns’ Uniform Specification” (LePUS) [5]. It, however, is difficult to capture the leitmotif of pattern using LePUS - even GoF patterns are not fully written in it. Progressive way of pattern description applicable in the context of pattern mining utilizes XML - ”Design Pattern Markup Language” [2] defines basic requirements on each class, operation and attribute so the group of them can be considered a pattern instance. The answer to the question ”Where to search?” starts with creation of system model. There are three basic ways how to get it automatically. First, static analysis of the source code comes in mind. It is straightforward, but the drawback is that it would require development of a new parser for each language analyzed system could use. Thus, lower level language would be useful - that is intermediate language like Java byte-code (JBC) or Common Intermediate Language (CIL).

64

M. Dobiš and Ľ. Majtás

All the languages of the .Net family (C#. Visual Basic, managed C++, J#, DotLisp, etc.) are translated to CIL when compiled. There exists also a transformation between the JBC and CIL using IKVM.NET [6]. Some behavioral analysis can be done directly from the statically written code - good examples are tools like Pinot (Pattern INference and recOvery Tool) [11] or Hedgehog [3] identify blocks of code and data flow between them to gain the simple image of the idea behind the code and its dynamic nature. More precise perspective of a system can be gain by dynamic analysis realizable through profiling API (e.g. CLR Profiler uses it). Running the system and monitoring its behavior might not be the most reliable method, but it is the only way how to gain some very useful information about it (e.g. Wendehals uses this, but his tool is not really automatic [14]). Last of the three questions is ”How to search?” There has been some works utilizing a graph theory to search the patterns in graph model of analyzed system, while mostly just static information were taken in account [2]. Similar to it, distance between graphs of an analyzed system and a pattern (difference in the similarity of graphs) was introduced in the literature [13]. A quick method of pattern recognition, useful mostly to speed up the search process in combination with something else, comes from the utilization of object oriented software metrics known from the algorithms for looking for ”bad smells” in the code [1]. Finally, rules and logic programming come alive in ”System for Pattern Query and Recognition” [12] in cooperation with already mentioned language LePUS with all its benefits and drawbacks.

3

Our Approach

The main reason for design pattern mining is making the system understandable and easier for modification. The problem of many mining approaches presented before is the relatively high false acceptance ratio, they often identify elements that just look like pattern instance, but they are certainly not. Therefore we decided to focus on preciseness of the searching method that would try to identify only correct pattern instances that meet all constrains a man could define on a pattern. The collaborating classes, methods and fields are marked as instance of particular design pattern when they really fit the design pattern definition; so the software engineer can gain benefits from using it. The first information that a software developer learns about a design pattern is mostly its structure. This static information is very important but is useless without the knowledge of the idea represented by pattern. What we want from our products - systems and programs - is the behavior rather than the structure and that is what specifies pattern most accurately. To provide reliable results we decided to take three different types of analysis that need to come to an agreement whether the examined elements complies with pattern constrains or not: structural, semidynamic and dynamic (run-time) analysis.

Mining Design Patterns from Existing Projects

3.1

65

Structural Analysis

The first and the easiest phase of the precise system analysis is the recognition of all types, their operations and data (attributes, local variables, method parameters). The search algorithm is based on graph theory, so we form the three types of vertex from these elements. Following information are recognized for each of them: – Unique identifier of each element. – Recognition whether it is static. – Identification of parent - the element in which the current one is defined inside. Type The Type vertex represents class, abstract class, interface, delegate, enumeration or generic parameter. It contains identification of element type (Boolean values indicating whether it is a class, interface, etc.). Special type of edge identifies the types the element derives from - this list contains the base type and all the interfaces implemented by it. Finally the child elements (inner classes, operations, attributes, etc.) are recognized forming new vertices connected to the current one with ”parent-identification” edge. Operation The business logic of applications is defined inside the methods and constructors. For these types of elements we recognize the following information: – Identification whether the operation is virtual. If so, the overridden virtual or abstract element is searched. – Recognition whether it is abstract. – Distinction between the constructors and common methods. – Returned type. – Parameters and local variables of the operation. Data Attributes, parameters and local variables are represented as the vertices of type data having the original scope stored as the vertex attribute. Each data field has its type (identified by an edge connected to the vertex standing for the type). The type of collections is not important when looking for design pattern instances. The important information is the type of elements in the collection in combination with additional information, that the reference (the data field) is not only one instance, but it stays for a group of elements of the recognized type.

66

M. Dobiš and Ľ. Majtás

Event Some modern object oriented languages define language level implementation of design pattern Observer. In .Net, the definition of events is similar to common class property - it has its type (delegate) and name. The difference is that during the compilation two new methods on the class containing the event are defined. These are used to attach and detach listeners (observers). From the design pattern mining point of view we can say, that the events are single-purpose. The definition of an event and references to it exactly define the Observer pattern instance that is implemented correctly. It is clear that when looking for this kind of pattern implementation, we can mark each occurance of the key-word. Thus, we store this information in the system model, but do not discuss this in the paper bellow. 3.2

Semidynamic Analysis

Application behavior is represented by methods, invocations between them and object creations. Some information can be gathered already from static representation of an analyzed system - the most important information is the call from one operation to another one. The necessity of the information about the calls was introduced in many recent works [2] [3] [11] concerning the design patterns mining. However, just a few of them inspected the whole body of operations in more detail. We find the placement of a method call (whether inside a condition, cycle or directly in a method) equally important as the basic recognition of the call. Most of the design patterns define the condition, that the particular call should be invoked just when an if-clause is evaluated as true (e.g. Singleton, Proxy) or it needs to be realized inside a cycle (e.g. Composite). It, however, should not forbid it - the inclusion inside a condition can be done due to many other reasons not affecting the design pattern instance. For some design patterns is also important the count of calls to a single operation placed inside the current operation (e.g. Adapter ). During the semidynamic analysis there we also analyze the class attributes. The access to a member variable from an operation brings some very useful information enhancing the image we can gain about the behavior from the statically written system. If a method plays the role of operation GetInstance in pattern Singleton, it is insufficient to have just the structural information, it needs to have a reference to the static field instance and modify it during the lazy initialization. The Fig. 1 presents the example results of the static and semidynamic analysis. 3.3

Dynamic Analysis

The only time, we can really observe the behavior of a system, is the run time. When we execute the analyzed system we can see, what is really happening inside the system. To do so, we decided to enrich the model (graph) with four simple information collected automatically.

Mining Design Patterns from Existing Projects

67

Fig. 1. Graph of the system structure enhanced with semidynamic information

Count of Instances Several design patterns say how many instances a particular class should have during one system execution. The simplest example should be the Singleton pattern - it is obvious that there needs to be exactly one instance of the class. The suitability and the goal we want to achieve by counting instances of concrete types is obvious. We decided to increase the number also for class A when an instance of class B is created whereas B derives from A. The reason for doing this is the fact that patterns usually do not forbid to derive from classes playing the roles in pattern instance. Thus, there might be a class that derives from Singleton but the method GetInstace still has to return the same object - Singleton needs to have just one instance no matter how many subclasses of it are defined in the system. Count of the Operation Invokes In the previous section we have already introduced the importance of the information how many times an operation was invoked. The Prototype example illustrates the comparison of the count of operation Clone invokes to the count of instances of a particular type. More common however, is the comparison to count of invokes of calls done from a particular operation (useful when searching for e.g. Composite or Proxy). Thanks to this information it is easy to verify whether the placement of a call inside a loop really increases, resp. the placement inside a condition decreases, the count of call executions. Using this information we can check also whether e.g. Composite really does its job and groups more components forming a tree structure.

68

M. Dobiš and Ľ. Majtás

Less common is to compare count of invokes of two separate operations. The reason is that mostly we do not know whether the target operation really gets executed - there might be lazy binding and the pattern definition would be useless. We could increase the count of invokes not only for the operation really called, but also for the overridden one. It might seem similar to the situation we have with the classes (previous chapter) but there are some differences. First of all, it is sometimes useful to distinguish exactly the called operation and modifying the count of overridden method would make it a little bit harder. The most important difference, however, is that we have another useful information when considering the operation invokes - we can identify the source and desired target by monitoring invokes of the calls from one operation to another. Count of the Calls Invokes The call from an operation is mostly polymorphic - its target is a virtual method that can but (in case it is not abstract) does not have to be overridden in a subclass. As described in previous section, this information can serve as verification of the real usage of a loop or a condition during the system run time. A good example is the Proxy pattern, where we can observe whether the condition really leads to lower calls to the RealSubject and is not just a result of coding standards or an accident. Count of Changes in Attributes Some patterns require tracking the value-changes in data variables. It might be interesting to monitor changes in all of them including local variables and method parameters, but we do not find this really useful and it would lead to performance problems due to many logging. What we find useful and sufficient is to count, how many times a value in a class attribute changes. The importance of tracking the changes can be seen in several design patterns -even when considering the very simple pattern Singleton we can propose a restriction that value stored in the static field instance should change just once. More changes would cause the program to loose the reference to the only instance, thus the pattern instance would behave incorrect. The most important, however, is the value to identify patterns Strategy and State. They have been discussed many times in literature so far [2]. When trying to recognize these patterns in a system automatically, most of the approaches presented earlier simply sets the instance as ”Strategy or State” - since they were using just the static analysis they were unable to distinguish one from other. The approaches that took the challenge and proposed the ability to distinguish them used some additional information, restriction that do not fit always and were added by them [3] [11]. Very common is the definition that a concrete state needs to know about its successor (one concrete state has reference to another concrete state) or the context simply creates the concrete states. This is usually true and is a very good assumption. We have identified different assumption that allows us to recognize these patterns: states should change, whereas strategies

Mining Design Patterns from Existing Projects

69

should not. This means that we need to know whether the attribute in Context class (its reference to abstract state or strategy) changes or not. We can say that the Strategy pattern says about algorithm a context can be configured with. Strategy encapsulates behavior used by a system, its part or a single class and it should not change during the client (Context ) life time. Thus, the restriction we placed is, that there can not exist any class that contains a parameter of type Strategy (reference to abstract strategy) that changes too many times - the highest possible count of changes in the field referencing from the Context to the Strategy is the count of instances of the Context class. Having the Strategy clear, we know how to find a State - when all the other requirements (structural, semidynamic, other dynamic restrictions) are met, there needs to be a Context class that has an attribute of type State that was changed (the value stored in the variable was changed) more times than the Context class was instantiated. 3.4

Design Pattern Model and the Search

We have introduced several constraints that can be used to exact recognition of design pattern instances. Because of these new constraints, we had to develop a new pattern description that includes improved structural and behavioral information. As we mentioned earlier, the analyzed system is represented as a graph with four kinds of vertices: type, operation, data and call. Each type of vertex has its own attributes (as they are described in chapters 3.1, 3.2 and 3.3) and can be connected with the other vertices using typed edges. The pattern is a rule that describes constraints on a subgraph of this graph - its vertices including values of the attributes, types and edges. Patterns usually define roles that might (or should be) played by more system elements - e.g. they define a concrete strategy, but expect that there will be more of them in a single instance of the pattern. It means that the multiplicity of items playing role concrete strategy should be at least 2. The multiplicity is crucial for all patterns (defining the minimal and maximal value of it for each pattern element) - it is clear that there should not be a public constructor available in the class Singleton, thus its multiplicity needs to be exactly 0. There needs to be at least one private constructor, so multiplicity of this element has the minimum at 1. The multiplicity is even more interesting when we look for an Abstract Factory instances - when we take the definition of pattern very precisely, we can propose a constraint on count of abstract products demanding it to be the same as the count of methods of the factory that create objects of different types. The minimal and maximal value is used also for all the information gathered using the dynamic analysis and can be set as constant number or as a reference to another numeric value evaluated on the pattern instance.

4

The Tool

To prove our concept we have developed a complex reverse engineering tool that is able to analyze any system built on the .Net platform and search the instances of design patterns defined in an editable catalogue (see Fig. 2 for the screenshot

70

M. Dobiš and Ľ. Majtás

Fig. 2. The results dialog window of the tool

of the tool). The analysis process starts with selection of assemblies (DLL and EXE files) and specifying namespaces that should be included. The content of the assemblies is written in Common Intermediate Language, that is produced by every compiler of all the languages of the .Net family. CIL can be read in various ways. The simplest one is the usage of the reflection that is commonly available in the .Net environment and is sufficient for the needs of structural analysis. The content of the operations that is investigated by the rest of the analysis process is available as plain CIL. We find here all the references to attributes (data fields), method calls and recognize whether they are positioned inside a condition, loop or directly in the method body. Finally, the dynamic analysis is done using .Net profiling API that allows us to inject logging instructions into every operation of the analyzed system. This is done before Just-In-Time compilation (from CIL to machine code) of each method starts. Before we could search for something, we needed to define it. Therefore we have created an editable catalogue of design patterns stored in an XML-based language that we have created from original Design Pattern Markup Language (DPML) [2] enhancing it by the features we added (we call it DPMLd ). The search for design patterns instances itself is based on graph theory and utilizes GrGen.Net [8]. GrGen.Net allows a developer to define his own model of graph that contains typed vertices, each type of vertex having its own attributes and connected with other vertices using typed edges. Upon the defined graph, there can be a graph-rewrite-rule created. The rule consists of conditional and changing part and can be used to specify conditions on subgraphs we want to search for. The tool we created transforms the graph of analyzed system into the GrGen.Net form and produces the graph-rewrite-rules from specification of design patterns. Finally, it collects the found subgraphs - basic fragments of candidates of design pattern instance (e.g. group of vertices that represent an instance of State with

Mining Design Patterns from Existing Projects

71

only one concrete state). These fragments are grouped together if they have common ”group-defining” elements - this is for example the abstract state class, or the template method. Which elements are the ”group-defining” is defined by the pattern and it can be any type, operation or data. The last step of the search is done when subgraphs are grouped into the candidates. It consists of multiplicity checks verifying the correct count of elements in the pattern instance.

5

Results

The Fig. 3 illustrates the benefits of the individual steps of the analysis we proposed in this article. It contains wrong and good implementations of the simplest of the GoF design patterns - the Singleton.

Fig. 3. Experiments with singleton pattern

Structural analysis is the first what comes in mind when we talk about mining of design patterns from existing projects. It checks many conditions - when considering the Singleton, it checks whether there is no public constructor and at least one private one in a class that contains static attribute of its own type

72

M. Dobiš and Ľ. Majtás

and a static method returning the type. However, all these conditions are met already in the case of class NearlySingleton1 (part A in the figure). Even more, the method GetInstance has reference to the instance data field and calls the private constructor. The semidynamic analysis checks all this and adds another feature - it requires the call to be placed inside a condition (if-clause). It might seem enough, but as we can see the NearlySingleton2 (part B in the figure) fits also these constraints and still is not a correct instance of the singleton pattern. Finally, the dynamic analysis adds some something that ensures the correctness - it checks the count of instances of the class (to be more exact it checks also the count of value changes in the instance field and count of method and call invokes) and verifies that the Singleton1 and Singleton2 are the valid Singleton pattern instances in the system. Please note, that the call to the private constructor in the Singleton2 is not placed in a condition as it is written in the code. However, we can say there is a hidden (suppressed) else block because the precious if-block ends with the return statement (the tool recognizes this correctly). We have filled the catalogue of the implemented tool with all GoF design patterns having one group of implementation variants for each pattern. This means that all common implementation variants are found, but some correct pattern instances that rely on transitive relations might stay undiscovered. The resolution to this is by adjusting the level of accuracy of the pattern definition or by adding the definitions of the additional variants (all using the GUI of the tool; automatic transitive relations are to be added during future work). The Observer and Iterator patterns are also included. We, however, decided not to search for the language-level implementation of them - this would be just the keyword based search for event or foreach. We defined these two as they are described in the GoF catalogue and search just in the client code. As expected, none of the projects we tested was ”reinventing the wheel” (they used the language level features instead of coding it at their own). Thus, we do not show these results in the tables bellow. We have checked our tool on the code of our tool itself (PatternFinder ). We chose our own tool for examination because it is an untrivial piece of code and we know about occurrence of all instances in it. The tool was able to find all the pattern instances correctly (except Mediator - it did not find it since it has colleagues made from system types that were skipped during the analysis process). It was also able to find some pattern instances we included unintentionally. The other tests were made on both - the free (mostly open source) and the commercial projects on the .Net platform (since we do not need sources, we need just the DLL and EXE). The Table 1 presents results of the examination executed on the different projects. Please note that we looked just for a single variant of each design pattern (resp. small group of variants covered using single pattern description in the DPMLd pattern language we proposed). The variants can be modified or some new one can be added to the tool using the editor it contains or by writing it as the XML. The table columns marked with S are based on static (structural and semidynamic) analysis and the D columns contain results that came from complete

S

Paint.Net D

S

SharpDevelop D

0/0/0 14 / 1 / 0 7/1/0 6/2/0 2/1/0 152 / 16 / 7 1585 / 73 / 24 451 / 30 / 5 13 568 / 285 / 71 1 249 / 100 / 39 0/0/0 188 / 2 / 2 0/0/0 3040 / 7 / 0 193 / 3 / 0 6/1/1 20 / 1 / 1 12 / 1 / 1 624 / 14 / 14 66 / 3 / 3 0/0/0 0/0/0 0/0/0 3/1/1 0/0/0 20 / 1 / 0 43 / 3 / 0 4/1/0 7054 / 16 / 3 2 565 / 5 / 1 48 / 1 / 1 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 16 / 5 / 0 0/0/0 3/1/0 0/0/0 4/1/1 25 / 1 / 1 1/1/1 24 / 2 / 2 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0 / 0 / 0 12 672 / 2 / 2 0 / 0 / 0 0/0/0 0/0/0 14 / 1 / 1 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 8/2/2 2/1/1 0/0/0 0/0/0 17 / 3 / 3 33 / 3 / 3 0/0/0 15 / 4 / 4 1/1/1 6/2/2 0/0/0 0/0/0 7/2/2 7/2/2 0 / 0 / 0 325 / 18 / 12 110 / 2 / 1 1528 / 43 / 25 428 / 23 / 14 237 / 9 / 9 591 / 43 / 23 171 / 16 / 11 7924 / 127 / 47 1476 / 75 / 26 14 / 2 / 1 87 / 14 / 2 41 / 5 / 1 17 / 5 / 0 0/0/0 51 / 1 / 1 0/0/0 0/0/0 0/0/0 0/0/0

PatternFinder S D

Abstract Factory 0/0/0 Adapter 389 / 25 / 7 Bridge 0/0/0 Builder 9/1/1 Chain of Respon. 0/0/0 Command 54 / 1 / 0 Composite 96 / 1 / 1 Decorator 0/0/0 Facade 1/1/0 Factory method 9/1/1 Flyweight 0/0/0 Interpret 0/0/0 Mediator 23 / 1 / 1 Memento 0/0/0 Prototype 0/0/0 Proxy 17 / 3 / 3 Singleton 6/2/2 State 42 / 1 / 0 Strategy 394 / 11 / 11 Template Method 14 / 2 / 1 Visitor 82 / 1 / 1

Pattern

Table 1. Experiments on existing projects

D 4/1/0 30 / 12 / 7 27 / 1 / 1 0/0/0 0/0/0 147 / 4 / 1 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 108 / 5 / 4 212 / 18 / 10 4/1/0 0/0/0

NUnit 14 / 1 / 0 247 / 28 / 11 96 / 1 / 1 27 / 1 / 1 0/0/0 398 / 4 / 1 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 1/1/1 0/0/0 771 / 13 / 6 161 / 18 / 11 7/3/0 0/0/0

S

Mining Design Patterns from Existing Projects 73

74

M. Dobiš and Ľ. Majtás

static and dynamic analysis Each table cell contains three numbers formatted like x / y / z, where: x - count of all subgraphs (smallest fragments that meet the basic requirements). y - count of all candidates that arrised from grouping of the subgraphs. z - count of the found pattern instances.

6

Conclusions and Future Work

In the previous sections we have introduced a method for searching instances of design patterns in an intermediate code and a tool that is a proof-of-concept. We have focused on preciseness of search results, therefore we have proposed a method based on three different types of analysis. All of them need to agree before they mark the pattern instance, so they together provide interesting results with low false acceptance ratio. The implemented tool provides identification of pattern instances in the intermediate language of the .Net platform. Choosing intermediate language as an input to the analysis removes the necessity of access to the source code. As a result we are able to check any software developed for the .Net platform, including COTS products provided by third parties. The search process is driven by a pattern specification which is written in an XML-based language. The tool provides a GUI editor for the language, what allows users to modify pattern descriptions or specify other patterns. Through modification of a pattern description a user can even configure the level of search preciseness. In the future, we would like to improve our specification language to allow searching more variants of design patterns. An interesting approach in this area has been introduced by Nagl [10]. He uses feature modeling [4] for specification of design pattern variability. Another improvement can be gained by allowing the transitive relationships which are sometimes parts of the software design (for example indirect inheritance, multiple code delegation, etc.). Acknowledgement. This work was partially supported by the project of APVV (Slovak Research and Development Agency), No. APVV-0391-06 ”Semantic Composition of Web and Grid Services” and the Scientific Grant Agency of Republic of Slovakia, grant No. VG1/3102/06.

References 1. Antoniol, G., Fiutem, R., Cristoforetti, L.: Using Metrics to Identify Design Patterns in Object-Oriented Software. In: Proceedings of the 5th International Symposium on Software Metrics, pp. 23–34. IEEE Computer Society, Washington DC (1998) 2. Balanyi, Z., Ferenc, R.: Mining Design Patterns from C++ Source Code. In: Proceedings of the International Conference on Software Maintenance, pp. 305–314. IEEE Computer Society, Washington DC (2003)

Mining Design Patterns from Existing Projects

75

3. Blewitt, A., et al.: Automatic Verification of Design Patterns in Java. In: Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering, ACM, New York (2005) 4. Czarnecki, K., Helsen, S., Eisenecker, U.: Staged Configuration Through Specialization and Multi-Level Configuration of Feature Models. Software Process Improvement and Practice, Special Issue on Software Variability: Process and Management 10(2), 143–169 (2005) 5. Eden, A.H.: Precise Specification of Design Patterns and Tool Support in Their Application. PhD thesis, University of Tel Aviv (1999) 6. Frijters, J.: IKVM.NET Home Page, http://www.ikvm.net/index.html (accessed May 5, 2007) 7. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley professional computing series (1995) ISBN 0-201-63361-2 8. Geiss, R., et al.: GrGen.NET, www.grgen.net (accessed November 4th, 2007) 9. Mapelsden, D., Hosking, J., Grundy, J.: Design Pattern Modelling and Instantiation using DPML. In: Proceedings of the Fortieth International Conference on Tools Pacific: Objects for Internet, Mobile and Embedded Applications, pp. 3–11. CRPIT Press, Sydney (2002) 10. Nágl, M. (supervised by Filkorn, R.): Catalog of software knowledge with variability modeling, Master thesis, Slovak university of technology, Faculty of informatics and software engineering (2008) 11. Shi, N., Olsson, R.A.: Reverse Engineering of Design Patterns from Java Source Code. In: Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering. IEEE Computer Society, Washington (2006) 12. Smith, McC, J., Stotts, D.: SPQR: Flexible Automated Design Pattern Extraction From Source Code. In: 18th IEEE International Conference on Automated Software Engineering, pp. 215–225. IEEE Computer Society, Washington DC (2003) 13. Tsantalis, N., et al.: Design Pattern Detection Using Similarity Scoring. IEEE Transactions on Software Engineering 32(11), 896–909 (2006) 14. Wendehals, L.: Improving design pattern instance recognition by dynamic analysis. In: Proceedings of the ICSE 2003 Workshop on Dynamic Analysis, pp. 29–32. IEEE Computer Society, Portland (2003)

Transformational Design of Business Processes for SOA Andrzej Ratkowski and Andrzej Zalewski Warsaw University of Technology Department of Electronics and Information Technology {[email protected], [email protected]}

Abstract. By describing business processes in BPEL (Business Process Execution Language) one can make them executable. Then a problem arises how to assure that some non-functional requirements concerning e.g. performance of these processes, are met. In the paper a transformational approach to design of business processes is presented. To check equivalence of business processes resulting from the transformations, a BPEL description is converted to Process Algebra (Lotos version) and model-checking techniques are applied. The paper contains also an example of applying the proposed approach in a real-life situation. Keywords: SOA, BPEL, business process design.

1

Introduction

The ability to define and execute business processes seems to be one of the most important advantages introduced by the research and commercial developments on Service-Oriented Architectures (SOA). The two worlds of business modeling and software systems development have never been closer to each other – it is now possible to express software requirements and business processes in terms of services. BPEL has become a standard for defining executable business processes. This in turn triggered an extensive research on the modeling and verification techniques suitable for BPEL-like notations. The recent research is concentrated on converting BPEL processes to one of the formal models that can be analysed with model-checking techniques. A survey of such approaches can be found in [3]. It reveals that all the most important formal modeling techniques developed for concurrent systems are applicable here: Petri nets (basic model, high-level, coloured) – (see e.g. [23], [21], [28]), Process Algebras – (see e.g. [12], [11]), Lotos – (see e.g. [9], [25]), Promela and LTL – (see e.g. [13], [15]), Abstract State Machines – (see e.g. [7], [26]), Finite State Automata – (see e.g. [11]). These conversions make possible deadlock and livelock detection as well as reachability analysis with automated model checkers. The approaches presented above accompanied by appropriate verification techniques can detect certain flows in BPEL processes. However, they are not methods of business processes design – they do not provide any guidance on how to Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 76–90, 2011. c IFIP International Federation for Information Processing 2011 

Transformational Design of Business Processes for SOA

77

improve the quality attributes of designed systems like maintainability, performance, reusability etc. This is what our approach is aimed at. In this paper we advocate an idea of transformational design of BPEL business processes in which specified behavior remains preserved, while quality attributes get improved. There are three basic roots of our approach: 1. Software refactoring – the approach introduced by Opdyke in [20], further developed in [17], in which the transformations of source code are defined so as to improve its quality attributes; 2. Business process design – in the realm of SOA informal or semiformal methods dominate the research carried out so far – e.g. Service Responsibility and Interaction Design Method (SRI-DM) [14]; 3. Business process equivalence – there have already been developed several notions of the equivalence between business processes based on Petri Nets [16] and Process Algebras [24]. The transformations of Business Processes are in the core of our approach and represent similar concept as popular software refactorings. In a formal Process Algebra model of business processes there have been introduced our original notion of business process equivalence (explained and discussed in section Behavioral Equivalence) and it has been proved that the defined transformations create processes equivalent to the one being transformed. These transformed processes are compliant in terms of their behavior, however, quality attributes have changed. This provides a foundation for the transformational design method in which a starting BPEL process is subject to a series of transformations yielding as a result behaviorally compatible model with improved non-functional properties like modifiability, maintainability, performance, reusability etc. The rest of the paper has been organized as follows: the section Transformational Approach describes generally concept of our transformational approach, sections Behavioral Equivalence drills down formal aspects of our method, finally section Process Design Example shows practical example of the application of the proposed approach.

2

Transformational Approach

The process of transformational design of business processes has been depicted in figure 1. 1. The transformational desing starts from establishing reference process representing only functionality of the process, order of the activities, relations between them as well as exchanged data and external services invocations. In following iterations the original process is gradually changed by refactoring transformations [22], [17] like: – Service split – dividing one complex services into two or more more simple ones,

78

A. Ratkowski and A. Zalewski

Fig. 1. Process transformation algorithm

2.

3.

4.

5.

– Service aggregation – opposite to service split: composing two or more services into one larger, – Parallelization – making serial activities to run in parallel, – Asynchronization – replacing synchronous communication protocol with asynchronous one. The above transformations are referred to as refactorings or transformations and are only examples of possible refactorings. A few independent refactorings or transformations executed on a given process create a few alternative processes, which should be equivalent to the original one or at least changes in behaviour should be known. Behavioral equivalence verification step is aimed at checking behaviour preservation. In this step formal methods of Process Algebra (PA) [5] are used. The result of verification is either elimination of not-equivalent alternative or acceptance of changes in behaviour that transformations caused. The transformation changes behaviour is exactly known thanks to PA formalism. After eliminating some of the alternatives or accepting all of them, alternatives are evaluated against non-functional properties like: – performance, – safety, – maintainability, – availability, – or any important property. The measure of each property is calculated e.g. with the metrics [18], models [8] or simulation. A single alternative is selected from the set of acceptable processes. This is based on the evaluation performed in the previous phase as well as the predefined desing preferences.

The above steps should lead from the process, which is correct from functional point of view, to the process that has desired non-functional quality attributes. All steps of algorithm are guided by a human designer and supported by automatic tools that may:

Transformational Design of Business Processes for SOA

– – – –

3

79

Suggest possible transformations of reference process, Verify behavioral equivalence, Compute quality metrics of alternatives, Point out quality attribute trade-off points.

Behavioral Equivalence

Behavioral equivalence verification is based on the transformation of BPEL processes to Process Algebras [5], which is a formal model, particularly suitable for the modeling of concurrent, loosely coupled and asynchronously communicating systems such as BPEL business processes. 3.1

Process Algebra for Behavioral Equivalence

We use LOTOS [2] implementation of PA as a model of BPEL process. To achieve this we have devised a mapping from BPEL to PA terms. There have already been proposed a number of BPEL to PA mappings – e.g. [10] or [4], however, they do not meet the needs of transformational design as they define full semantic equivalence preserving every detail of the internal structure of the process (i.e. the order of activities and their relation with other activities). This strictness narrows the possibility of changing the process structure or even makes it impossible. Therefore, we need a looser equivalence definition to assure that enough freedom is given to the trasformation of business processes. A separate issue is that transformations should produce simple models with possibly smallest statespace (the mappings referred above produce rather complicated models). During design procedure a few alternative process structures are considered and the equivalence of each of them has to be verified – this in turn should not be too time-consuming if the method is expected to be of a practical importance. Most important mappings of BPEL activities to PA formulas have been presented in table 1. The mappings neither take into account data values nor condition fulfillment. This is motivated by simplicity of the model and its more efficient verification with a model-checker. There has also been added an artificial mapping of activity which is not explicit part of BPEL but is necessary for equivalence verification. This is activity dependency mapping. Let us assume that there are two activities in BPEL process that are not directly attached to each other (by e.g. <sequence> or <switch>) but by shared variable, like in the following example: ...

80

A. Ratkowski and A. Zalewski

Table 1. Sample mappings BPEL activities to PA formulas BPEL external service invocation

LOTOS Process Algebra



process invoke_invokeName [inputName,outputName] := hide tau in ( inputName;tau;outputName;ended;exit ) endproc

receive message

process receive_receiveName [variableName] := hide tau in ( variableName;tau;ended;exit ) endproc

assign variable value

process assign_assignName [fromVar, toVar] := hide tau in ( fromVar;tau;toVar;ended;exit ) endproc

parallel execution < ... name="activityA"/> < ... name="activityB"/> [...]

process flow_flowName[dmmy] := hide ended in ( activityA |[ended]| activityB ... ) endproc

sequential execution <sequence name="seqName"> < ... name="activityA"/> < ... name="activityB"/>[...]

process sequence_seqName[dmmy] := activityA >> activityB >> ... endproc

conditional execution <switch name="switchName"> < ... name="activityA"/> < ... name="activityB"/>

process switch_switchName[dmmy] := hide ended in ( activityA [] activityB ... ) endproc

Transformational Design of Business Processes for SOA

81

Then activity dependency mapping will be : process act_dependency[dummy] receive_ReceivePurchase[PurchaseOrder] |[PurchaseOrder]| assign_assignOrder[PurchaseOrder, ShippingRequest] endproc The activity dependency expresses indirect dependency of two activities that one needs output data from another, no matter what structural dependencies (sequence or parallel) in the process are. 3.2

BPEL Behavioral Equivalence

The key structure of our definition of behavioral equivalence is minimal dependency process (MDP). MDP is the process that is as simple as possible but still gives the same response for given stimulation as original process. MDP is constructed as set of activities executed in parallel that do not interact with each other. It is achieved by relaxing unnecessary structural activities that are in the original process. Current section supplies theoretical basis for the construction of MDP and the evidence that it can be used for process equivalence definition. There are few approaches to determine behavioral equivalence (or other words behaviour preservation) of refactored processes. In [20] author proposes definition that two systems are equivalent when response for each request is the same from both systems. According to [19] communication oriented systems are equivalent, if they send messages in the same order. In case of transformational design we assume that every service fulfills stateless assumption. It means that when BPEL process invokes external service then every response for some request is the same and do not depend on history. This assumption leads to the conclusion that state of external services (and all environment) is encapsulated inside the invoking service. To make this assumption usable and to prove how it can be used we need basic PA theory. → B B− x

(1)

The above formula means that process B reaches state B’ after receiving event (message) x Now PA semantics is defined using inference rules that has form: premises (sidecondition) conclusions

(2)

82

A. Ratkowski and A. Zalewski

For example parallel execution (without synchronization) || has 2 symmetric rules : x

x

B1 − → B1 x

B1||B2 − → B1 ||B2

and

B2 − → B2 x

B1||B2 − → B1||B2

(3)

and precedes (sequential composition) >> has 2 rules : x

σ

B1 − → B1 x

B1 >> B2 − → B1 >> B2

and

B2 − → B2 i

B1 >> B2 − → B2 where σ is successful termination and i is unobservable (hidden) event. If external services S is stateless then: y

∀y ∈ Y S − →S

(4)

(5)

where Y is a set of all events. This means that every event, generated externally by the subject service, does not change the state and answer of the service. To analyse BPEL process using PA terms, the BPEL process has to be translated into PA using the mapping mentioned above. The result of the translation is a set of PA processes that are sequentially ordered by BPEL steering instructions – sequences, flows, switches and so on. Additionally, part of the mapping is activity dependency process. This artifact symbolizes data dependency between the activities (one needs data generated by the other one). Let us denote it with dependency operator A]x]B

(6)

which means that state B can be started after A is successfully terminated and event x is emitted (or received). Below we illustrate the foundations of the behavioral equivalence concept. Let us consider a process that has a set of operations connected with dependency sequence: (A]x]C]z]D) (7) C waits for A result and D for C result. Apart from the above dependency, the process has also structural sequence defined by <sequence> instruction A -> B -> C -> D, where B is an instruction, which is not connected by activity dependency. We can relax the structural sequence and consider the process as: (A]x]C]z]D)||B

(8)

That means, we can treat (A]x]C]z]D) and B as two parallel, independent activities. Proof that ( 8) is true for stateless services 1. if there is no external service, ( 8) is true by the definition because there is no interaction between (A]x]C]z]D) and B

Transformational Design of Business Processes for SOA

83

2. if there is stateless external service S, then: y

→ ((A]x]C]z]D)) ||S ∀y(A]x]C]z]D)||S − and

y

→ S||B  ∀yS||B −

(9) (10)

which leads to : y

y

→ (A]x]C]z]D) ⇒ (A]x]C]z]D)||B − → (A]x]C]z]D) ||B (A]x]C]z]D) − and

y

y

B− → B  ⇒ (A]x]C]z]D)||B − → (A]x]C]z]D)||B 

(11)

(12)

Equation ( 12) is parallel execution inference rules ( 3) which is proof of ( 8) If S was statefull, then y

∃y(A]x]C]z]D)||S − → (A]x]C]z]D) ||S  then

y

→ (A]x]C]z]D) ||B  (A]x]C]z]D)||B −

(13)

(14)

this would mean that there are some interactions between (A]x]C]z]D) and B, and that they can not be treated independently. The above theory makes possible to break the whole BPEL process into a set of subprocesses, which depend on each other only by data dependecies represented as activity dependencies. This technique can be related to program slicing [1] used broadly in source code refactoring. BPEL service with defined activity dependencies and without structured constraints (sequences, flows, conditional and so on) is called minimal dependency process (MDP). Such a MDP becomes a basis for verification of equivalence of transformed (refactored) process with the requirements specified by MDP. After refactoring, new (refactored) process has to be translated to PA and its PA image must fulfill preorder relationship specified by MDP, therefore, refactored process has to be a subgraph of MDP’s states graph. 3.3

Application of PA in Refactoring

As it was mentioned in the transformational approach introduction, PA formalism can help to decide if examined process is equivalent to reference one or points changes between processes. This is done by comparing execution state graphs of reference and refactored process. There are two possible results of this examination: – execution graph of refactored process is subgraph of MDP reference process – this means that refactored process is equivalent to reference process or

84

A. Ratkowski and A. Zalewski

– execution graph is not subgraph of MDP reference process – processes are not equivalent, but the information that can be obtained from the comparision is: what edges or nodes of execution graph are in refactored process but does not exist in MDP graph. Those extra edges and/or nodes are related to instructions or parts of code that makes importand diference between original and refactored process. The human designer can then decide, if theese differences are acceptable or not, in context of refactored process. 3.4

Algorithm and Tools for Equivalence Verification

Algorithm of equivalence verification consist of three steps: 1. Translating BPEL process to minimal dependency process (MDP) – this step is made only once at the beginning of refactoring process; 2. Translating BPEL process to its PA image; 3. Checking preorder relationship of PA image with minimal dependency process. For purposes of the test, translation BPEL to PA was made by using XSLT [27] processor, as the PA processor Concurrency Workbench for New Century (CWBNC) [6] has been used. The structure of the verification system is presented in figure 2.

Fig. 2. Structure of verification process

4

Process Design Example

Entire approach can be illustrated on a practical example of an order handling process. During the transformations two quality attributes are taken into account: performance and reusability. First of them is measured by a response time under given load, the latter one by a number of interfaces the whole considered system provides.

Transformational Design of Business Processes for SOA

4.1

85

Reference Process

The order handling process service is composed of three basic activities: invoicing, order shipping and production scheduling, which operate as follows: 1. A purchase order is received – it defines purchased product type, quantity and desired shipping method, 2. Shipping service is requested, which returns the shipping costs, 3. Invoice service provides the process with an invoice, 4. Production of ordered goods is scheduled with the request to scheduling service. All the activities are performed consecutively. The reference process with accompanying services is depicted in fig. 3.

Fig. 3. Purchase order handling reference process

4.2

Process Alternatives

The designer consideres three alternatives to the reference process shown in fig. 4: 1. Alternative (1): the purchase process first makes request to the shipping service then in parallel to scheduling and invoice services. 2. Alternative (2): the process runs parallely all three requests – to invoice, shipping and scheduling services.

86

A. Ratkowski and A. Zalewski

3. Alternative (3): a bit more sophisticated one – the reference service is splited into three separate services. First of them invokes shipping service, second one invokes invoice and scheduling services, the third one composes the other two subservices. 4.3

Equivalence Verification

Each of the three alternatives are verified whether they are behaviorally equivalent to the reference process. Technique of the verification has been described in section 4. The result of the verification is as follows: – Alternative (1) is behaviorally equivalent unconditionally, – Alternative (2) is not equivalent, because the request to invoicing and shipping services depends on the data received from shipping service. When all three requests start at the same time, we can not guarantee that the data from shipping service is received before the request to scheduling and invoicing services. This alternative cannot be accepted. – Alternative (3) is behaviorally equivalent. 4.4

Alternatives Evaluation – Performance

As it was mentioned at the beginning of the section, alternatives performance and reusability is assessed so as to chose a preferred process’ structure. Performance is measured as a mean response time under certain load level. The web service and connections between services can be modeled with queueing theory like M/M/1//inf system [8]. It means that requests arrive to the system independently with exponential interval distribution and response time is also exponentially distributed. Thanks to the above assumptions, average response time of the whole system can be estimated as a sum of average response times of its components: services and links between them. To make evaluation simpler, we assume that every network connection has the same average latency RN . So average response time of the reference process is: RRP = RBP ELR P + Rshipping + Rinvoicing + Rscheduling + 7RN

(15)

Please note that average response times of invoicing, shipping and scheduling are simply added, thanks to the fact that services are invoked consecutively. Let us assume additionally that the values of appropriate parameters are as follows: – – – – –

RBP ELR P = 2 ms (average time of processing of main BPEL process) Rshipping = 3 ms (avg. resp. time. from shipping service) Rinvoicing = 5 ms (avg. resp. time. from invoicing service) Rscheduling = 4 ms (avg. resp. time. from service) RN = 1 ms (avg. network latency)

Transformational Design of Business Processes for SOA

Fig. 4. Discussed alternatives for the reference process

87

88

A. Ratkowski and A. Zalewski

That gives RRP = 21ms. For alternative (1) average response time is: RA1 = RBP ELA1 + Rshipping + max(Rinvoicing , Rscheduling ) + 7RN

(16)

the difference between alternative (1) and reference process is that invoice and scheduling services are requested parallelly, so response time of parallel part is the maximum of response times of invoicing and scheduling processes. When we assume that RBP ELA1 = RBP ELRP then: RA1 = 17ms. Finally alternative (3) average response time is given by: RA3 = RBP ELA31 +RBP ELA32 +RBP ELA33 +Rshipping +max(Rinvoicing , Rscheduling )+11RN (17)

that yields: RA3 = 25ms 4.5

Alternatives Evaluation – Reusability

Total number of interfaces provided by the considered system (i.e. process and acompanying services) has been used as a reusability metric (the more interfaces the higher reusability). Reference process and alternative (1) deliver four interfaces: one to the purchase process and three to the elementary services: invoicing, shipping and scheduling. Alternative (3) delivers six interfaces: three to the elementary services, one to the composite service (process) and two new interfaces to two subservices. All the above data is gathered in table 2. Table 2. Quality metrics for the reference process and its alternatives Reference process response 21 ms

Average time Reusability Services quantity

4.6

4 1

Alternative 1 Alternative 3 17 ms

25 ms

4 1

6 3

Alternatives Selection

There is a trade-off between the two considered quality attributes: systems consisting of more basic services are more reusable at the expense of performance and vice versa. The designer has to decide according to assumed design preferences: when reusability is prefered – alternative (3) should be chosen, otherwise when performance is the most important attribute – alternative (1) should be preferred.

Transformational Design of Business Processes for SOA

5

89

Summary

The paper presents a transformational approach to the design of electronic business processes denoted in BPEL. The approach has been founded on a novel concept of business processes equivalence, which makes possible to construct business processes by their gradual transformations. Processes resulting from those transformations can be formally verified against their specification as well as against typical properties of concurrent systems like livenes or reachability. The designer, who steeres the transformations by evaluating non-functional attributes, is informed either that transformed process meets predefined requirements or which parts of process’ behaviour has changed. He can accept or reject such a non-equivalent transformation, beeing also assisted by supporting tools. The usefulness of our approach has been presented on a not-trivial example. The directions for tool support development have also been provided, some of these tools have already been implemented: e.g. BPEL to LOTOS transformation tool. Further research can include development of predefined transformations that have been proved to preserve a priori properties like process equivalence as well as the development of a business process design environemnt (software tools) integrating all the tools needed to support the presented approach. The challenge in building such tools is to make one consistent process out of all the separated method steps and to build an integrated development environment. Integrated tool can be built as an extension of one of the open-source software development environments like Eclipse or NetBeans.

References 1. Binkley, D., Gallagher, K.B.: Program slicing. Advances in Computers 43, 1–50 (1996) 2. Bolognesi, T., Brinksma, E.: Introduction to the iso specification language lotos. Comput. Netw. ISDN Syst. 14(1), 25–59 (1987) 3. Koshkina, M., Breugel, F.: Models and verification of bpel (2006) 4. C´ amara, J., Canal, C., Cubo, J., Vallecillo, A.: Formalizing wsbpel business processes using process algebra. Electr. Notes Theor. Comput. Sci. 154(1), 159–173 (2006) 5. Cleaveland, R., Smolka, S.: Process algebra (1999) 6. Cleaveland, R.: Concurrency workbench of the new century (2000), http://www.cs.sunysb.edu/~ cwb/ 7. Fahland, D., Reisig, W.: Asm-based semantics for bpel: The negative control flow. In: Abstract State Machines, pp. 131–152 (2005) 8. D’Ambrogio, A., Bocciarelli, P.: A model-driven approach to describe and predict the performance of composite services. pp. 78–89 (2007) 9. Ferrara, A.: Web services: a process algebra approach. In: ICSOC 2004: Proceedings of the 2nd International Conference on Service Oriented Computing, pp. 242–251. ACM Press, New York (2004) 10. Ferrara, A.: Web services: a process algebra approach, pp. 242–251 (2004) 11. Foster, H., Kramer, J., Magee, J., Uchitel, S.: Model-based verification of web service compositions. In: 18th IEEE International Conference on Automated Software Engineering, ASE (2003)

90

A. Ratkowski and A. Zalewski

12. Foster, H., Uchitel, S., Magee, J., Kramer, J., Hu, M.: Using a rigorous approach for engineering web service compositions: A case study. In: SCC 2005: Proceedings of the 2005 IEEE International Conference on Services Computing, pp. 217–224. IEEE Computer Society, Washington, DC (2005) 13. Fu, X., Bultan, T., Su, J.: Analysis of interacting bpel web services. In: WWW 2004: Proceedings of the 13th International Conference on World Wide Web, pp. 621–630. ACM, New York (2004) 14. Hofacker, I., Vetschera, R.: Algorithmical approaches to business process design. Computers & OR 28(13), 1253–1275 (2001) 15. Holzmann, G.J.: The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley Professional, Reading (2003) 16. Martens, A.: Simulation and equivalence between bpel process models (2005) 17. Martin, F.: Refactoring: improving the design of existing code. Addison-Wesley Longman Publishing Co., Inc., Boston (1999) 18. Seattle University Everald E. Mills. Software metrics, SEI-CM-12-1.1 (1988) 19. Moore, I.: Automatic inheritance hierarchy restructuring and method refactoring, pp. 235–250 (1996) 20. Opdyke, W.F.: Refactoring Object-Oriented Frameworks. PhD thesis, UrbanaChampaign, IL, USA (1992) 21. Ouyang, C., Verbeek, E., van der Aalst, W.M.P., Breutel, S., Dumas, M., ter Hofstede, A.H.M.: Formal semantics and analysis of control flow in ws-bpel. Sci. Comput. Program. 67(2-3), 162–198 (2007) 22. Ratkowski, A., Zalewski, A.: Performance refactoring for service oriented architecture. In: ISAT 2007: Information Systems Architecture And Technology (2007) 23. Hinz, S., Schmidt, K., Stahl, C.: Transforming BPEL to Petri Nets. In: van der Aalst, W.M.P., Benatallah, B., Casati, F., Curbera, F. (eds.) BPM 2005. LNCS, vol. 3649, pp. 220–235. Springer, Heidelberg (2005) 24. Sala¨ un, G., Bordeaux, L., Schaerf, M.: Describing and reasoning on web services using process algebra, p. 43 (2004) 25. Sala¨ un, G., Ferrara, A., Chirichiello, A.: Negotiation among web services using LOTOS/CADP. In (LJ) Zhang, L.-J., Jeckle, M. (eds.) ECOWS 2004. LNCS, vol. 3250, pp. 198–212. Springer, Heidelberg (2004) 26. Reisig, W.: Modeling- and Analysis Techniques for Web Services and Business Processes. In: Steffen, M., Tennenholtz, M. (eds.) FMOODS 2005. LNCS, vol. 3535, pp. 243–258. Springer, Heidelberg (2005) 27. W3C. Xsl transformations (xslt) version 1.0 (1999), http://www.w3.org/tr/xslt 28. Yang, Y., Tan, T., Yu, J., Liu, F.: Transformation bpel to cp-nets for verifying web services composition. In: Proceedings of NWESP 2005, p. 137. IEEE Computer Society, Washington, DC (2005)

Service-Based Realization of Business Processes Driven by Control-Flow Patterns Petr Weiss Department of Information Systems, Faculty of Information Technology, Brno University of Technology, Bozetechova 2, 612 66 Brno, Czech Republic [email protected]

Abstract. This paper deals with Service-Oriented Analysis and Design (SOAD). SOAD comprises requirements elicitation, analysis of the requirements to identify services and business processes and finally implementation of the services and processes. It is a heterogeneous approach that combines a number of well-established practices. The key question in SOAD is how to integrate the practices to model a true service-oriented system with all its requirements. The approach presented in this paper helps to bridge the semantic gap between business requirements and IT architecture by using a method for transformation of business process diagrams into service diagrams. The service diagrams describe how the process is realized by using services. In details, the method transforms diagrams denoted in Business Process Modeling Notation into a set of UML diagrams. The principle of the method is demonstrated in an example. Keywords: Service-Oriented Architecture, Service-Oriented Analysis and Design, Business Process Modeling, Service Specification, Composite Services.

1

Introduction

Service-Oriented Architecture (SOA) is a complex solution for analysis, design, maintenance and integration of enterprise applications that are based on services. Services are autonomous platform-independent entities that provide one or more functional capabilities via their interfaces. In other words, SOA is an architectural style for aligning business and IT architectures. If a new service is considered it has to fulfill both business requirements and the fundamental SOA properties such as loose coupling, service independence, stateless and reusability [4]. It means that Service-Oriented Analysis and Design (SOAD) should focus not only on services but also on business requirements. This paper introduces an approach for integration between Business Process Modeling and Service Modeling. The approach is based on a technique that transforms business process models into models of service orchestration by using control-flow patterns. Service orchestration represents realization of a business Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 91–102, 2011. c IFIP International Federation for Information Processing 2011 

92

P. Weiss

process. To be more specific, business process diagrams are denoted in Business Process Modeling Notation (BPMN) and service orchestrations are modeled by means of UML. The reminder of this paper is organized as follows. Section 2 containes an overview of main approaches that are relevant to the subject. Section 3 introduces the concept of primitive and composite services and presents the idea of service specification. Next, in Section 4 the transformation rules are explained. They are illustrated with an examplary business process in Section 5. Finally, Section 6 discusses advantages and disadvantages of our approach compared with the approaches presented in Section 2. Conclusions and future work are contained in Section 7.

2

Related Work

The work presented in this paper has been influenced by several different proposals. First of all, we should mention UML profiles for SOA. [1] introduced a simple UML profile that is intended to use for modeling of web services. [6] provided a well-defined profile for modeling of service-oriented solutions. In [11] it is showed how services and their extra-functional properties can be modeled by using UML. The ideas presented in these approaches are a good starting point to model both the structural and the behavioral properties of services by means of UML. However, Service Modeling needs to take into account some additional aspects. Primarily, we have to know the connection between business requirements and functional capabilities of modeled services. [13] introduced 21 patterns that describe the behavior of a business process. Next, [16] showed how these patterns can be modeled by means of UML and BPMN. The author discussed the readability and technical properties of each model. Furthermore, [17] analyzed using of Control-flow, Data and Resource patterns in BPMN, UML and BPEL. The relationship between BPMN and UML is also introduced in [2]. The BPMN is defined in [9]. The author describes a high-level mapping of a business process to UML 2.0 Business Service Model (BSM) that represents service specification between business clients and information technology implementers. Lastly, [7] addressed main problems of transformation between business process modeling languages. Particularly, ADONIS Standard Modeling Language, BPMN, Eventdriven Process Chains and UML 2.0 Activity Diagrams were mentioned.

3

Service Specification: Primitive and Composite Services

Within this paper, each service is modeled as a stereotype service that extends the UML class Component [8]. This concept is introduced in [15]. Every service interacts with its environment via interfaces. During an interaction, service can play two different roles: service provider or service consumer. These two roles are distinguished in the service model by means of a port. The provider port (stereotyped as <<prov>>) of a service implements interfaces that specify

Service-Based Realization of Business Processes

93

functional capabilities provided to possible consumers of the service, while the consumer port (stereotyped as <>) requires interfaces of defined services to consume their functionality. In our approach, we prefer a flat model to a hierarchical model of the serviceoriented architecture. For this purpose we introduce two types of services: primitive services and composite services. Primitive services are derived from service invocation tasks, and are responsible for providing functional capabilities defined by a task. A composite service is an access point to an orchestration of other primitive or composite services. It means that a composite service does not enclose its internal services participating in the orchestration and does not delegate its interfaces to them. It only represents a controller of those services, i.e. the composite service communicates with its neighboring services at the same level of hierarchy in the producer-consumer relationship. The flat model provides better reusability of services, because the context of a service is defined only by its implemented (i.e. provided) and required interfaces, not by its position in the hierarchy. A specification of each service includes description of its architecture and internal behavior. The architecture is defined by interfaces that the service provides and requires. Each service provides at least one interface at the consumer port. Such an interface involves service operations that realize the functional capability of the service. Parameters of these operations describe format of an incoming message. The internal behavior describes which actions are executed when an operation of the service is invoked. In the case of a composite service, the behavior describes an orchestration that this service provides. It means which actions have to be performed in order to execute the corresponding orchestration.

4

The Transformation

As mentioned above, SOAD provides techniques required for identification, specification and realization of services and service flows. It is obvious that the initial activity in the development of a new SOA-based system is the service identification. It consists of a combination of top-down, bottom-up, and middle-out techniques of domain decomposition of legacy systems, existing asset analysis, and goal-service modeling. The result of the service identification is a set of candidate services. In the context of this paper, the service identification is a prerequisite for the transformation. Since this paper is mainly focused on the transformation, the details about the service identification are omitted here. More about service identification can be found in [5]. The transformation consists of two basic steps. The objective of the first step is to identify which tasks from the Business Process Diagram (BPD) represent service invocations and therefore will be transformed into services. This decision takes into account such aspects as which service providers provide which services, Quality of Service (QoS) requirements, security issues, etc. [3] and is closely related with the results of the service identification. Such an analysis is beyond the scope of this paper.

94

P. Weiss Table 1. Transformation rules for basic BPMN elements BP pattern

Service pattern

Communication protocol

None

None

None

The second step, the transformation process itself, generates an orchestration of the identified services. The orchestration represents realization of the given business process. The transformation is based on transformation rules. Each rule defines how to transform a control-flow pattern (eventually basic BPMN element) into an UML service pattern. Each service pattern is described by its structure and by a communication protocol. Due to the limitation of space in this paper, only basic rules are introduced (see Table 1 to Table 3). Some rules include context information that is needed to understand the using of the rule. For this purpose, the actual transformation step is inserted into a red-line-bordered area. To distinguish a primitive service from a composite one, the convention used in this paper is to name a primitive service with a capital letter (e.g. serviceA) and a composite service with a number (e.g. service1). Besides, some BPD elements can by transformed in more than one way (see e.g. Table 2). Table 1 contains transformation rules for basic BPD elements. The first row of the table depicts a rule for a pool. A pool represents a business entity in the given process. Graphically, a pool is a container for the control flow between BPD elements. Each pool in a BPD is mapped to a corresponding composite service

Service-Based Realization of Business Processes

95

in a service diagram. The composite service is then responsible for the execution of that part of a business process that is modeled within the pool. Hereafter, we assume that all BPD elements belong to the processA pool, unless otherwise indicated. A pool can contain one or more lanes. Lanes model internal sub-partitions (usually called roles) within a business entity. These roles encapsulate a given part of the BP and ensure its execution. In the context of service diagrams, this relationship is modeled by means of packages. Next, a message start event is mapped to a message (implicitly asynchronous) and a message end event is mapped to a replay. The last row in Table 1 contains a transformation rule for a single service invocation task. Generally, a task represents some unit of work performed in a process that is not further modeled. A service task is a task that provides some sort of service. Graphically, it is used to depict a service task with a small sprocket-symbol in the upper right corner to distinguish a service task from a task. A service task in a business process diagram is represented by a primitive service in a service diagram. As mentioned above, Task1 (from Table 1) belongs to processA. It means that Task1 is executed within the scope of processA. As a result, a new service1 is created and connected to serviceA. This is made by means of an assembly connector. The connector defines that service1 provides some capabilities that serviceA requires. In this case, it means that service1 is controlled by serviceA. In the other words, serviceA is an access point to service1. The corresponding sequence diagram describes details of the communication between serviceA and service1. As we can see, the invocation of Task1 is modeled by means of an incoming message to service1. In Table 2, it is shown how to transform a sequence of two service invocation tasks. The transformation can be done in three different ways. The first one is to add a new primitive service to the existing service diagram and to specify the communication protocol in the corresponding sequence diagram (see Table 1, the first row). The alternative way is to create a new primitive service and a new composite service. These two services will be added to the service diagram as follows (see Table 2, the second row): service2 is the primitive service that represents Task2, and serviceB is the composite service that acts as a gate to service2 and service1. Hence, service2 is connected to serviceB and service1 has to be switched to serviceB if it was connected to another service before this transformation step. Interactions among these services are depicted in the sequence diagram. Lastly, the sequence of two service tasks can be transformed into a single primitive service. It is achieved through adding a new interface to the provider port of the existing primitive service and connecting this interface to the corresponding composite service. Hence, it follows that such a service provides functional capabilities that correspond to both of the tasks. When the service is invoked, the capability is chosen according to the message that is sent to the service. See Table 2 (the third row) for details. Generally, the first rule is usually used when we need to create a new standalone service. The second rule is used when we need to control the primitive services for some

96

P. Weiss Table 2. Transformation rules for the Sequence Pattern BP pattern

Service pattern

Communication protocol

reason, i.e. because of QoS or security issues. If we want to use an existing service with only some modifications, we can apply the third transformation rule. Transformation rules for passing of data in a BPD are in Table 3. In this case, a data object is sent from one task to another, via a sequence flow. The first row describes the transformation of a general data passing. As we can see in the sequence diagram, the composite service is responsible for forwarding data from one primitive service to the another one. This rule can be used also for tasks that are not adjacent to each other in a BPD. The alternative rule (the second row) can be used only for two adjacent service tasks. In this case, service1 just produces data that is needed to pass to service2. For this purpose, service1 has to be switched directly to service2 if it has been connected to another service before this transformation step. The sequence diagram then shows details of the communication among these services. At first, serviceA invokes service2. After that, service2 calls service1 and

Service-Based Realization of Business Processes

97

Table 3. Transformation rules for the Data-Passing Pattern BP pattern

Service pattern

Communication protocol

None

waits for the data. As soon as the data is passed, service2 can complete its processing and send the result message back to serviceA.

5

Example

Figure 1 shows an exemplary “Purchase Order” business process model. This example is adopted from [10]. As we can see, there are three roles, which are responsible for realization of the “Purchase Order” process: “Invoicing”, “Shipping” and “Scheduling”. Processing starts by receiving a purchase order message. Afterwards, the “Invoicing” role calculates an initial price. This price is not yet complete, because the total price depends on where the products are produced and the amount of the shipping cost. In parallel, the “Shipping” role determines when the products will be available and from what locations. At the same time, the process requests shipping schedule from the “Scheduling” role. After the shipping information is known, the complete price can be evaluated. Finally, when the complete price and shipping schedule are available, the invoice can be completed and sent to the customer. In this example, we assume that following tasks (from Figure 1) were identified as service invocation tasks: “Initiate Price Calculation”, “Complete Price Calculation”, “Request Shipping” and “Request Production Scheduling”. We can generate a service orchestration (see Figure 2) from this BPD by using the transformation rules mentioned in Section 4. The orchestration is composed from one composite and three primitive services. The composite service – the PurchaseOrder service – represents the

98

P. Weiss

Fig. 1. BPMN model of the Purchase Order process

Fig. 2. The derived service orchestration

Fig. 3. The service topology

business process itself. This service controles the rest of following primitive services. The PriceCalculation service provides two interfaces (i.e. two functional capabilities) iInitialPrice and iTotalPrice according to the “Initiate Price Calculation” and “Complete Price Calculation” tasks. Similarly, ProductionScheduling and Shipping provide functional capabilities specified by “Request Production Scheduling” and “Request Shipping”, respectively. Figure 3 depicts the service topology, which belongs to the orchestration. In Figure 2, we can also see that the PurchaseOrder service provides the iAsyncReplay interface at its consumer port. Each service that enables

Service-Based Realization of Business Processes

99

Fig. 4. The behavior of the PurchaseOrder service

asynchronous communication has to implement this auxiliary interface. Consumed services use this interface to send replies back to the consumer. As a composite service, the PurchaseOrder service is responsible to keep its subordinate services independent and stateless. This is done by controlling of passing of data between its subordinate services. The principle can be shown on the collaboration between PurchaseOrder and PriceCalculation (see Figure 4). In order to complete the invoice, the price has to be calculated. Consequently, the PurchaseOrder service requests the PriceCalculation service. PriceCalculation calculates the initial price and returns it to PurchaseOrder. PriceCalculation does not store the calculated price for later use, i.e. it does not hold any state information. When the service is invoked again (in order to calculate the final price), its initial state has to be set by sending of the initial price.

100

P. Weiss

Because this paper deals mainly with the issue of generating models of service orchestration from a BPD, it is payed less attention to specify single services. The details about messages, which are being passed between services, and details about architectures of every single one service mentioned in this example can be found in [12].

6

Discussion

The transformation technique presented in this paper is motivated by several approaches introduced in Section 2, especially by [16], [17] and [5]. Compared to these approaches, the technique proposed in this paper is primarily focused on realization of business processes rather than on modeling of business processes by means of UML. [2] provides a method for integrating Business Process Modeling and Object Modeling by treating each business process as a contract. The contract is a mediator between business clients and IT implementers. It specifies service providers playing roles in a collaboration fulfilling some business rules in order to achieve some business goals. Our technique follows this method by describing how to implement the business process by services in the context of SOA. [10] proposes a similar concept to our approach. However, that concept does not provide any description of the relation between business process diagrams and UML models. What is more, it contains a number of incorrectness. The most significant one is that the stateless of services (the fundamental SOA principle) is ignored. Services are designed in such a way that they store data affecting their functionality between two single incoming requests. Our approach solves this problem by using a composite service (see Section 3 and 5). Furthermore, in our approach, services’ interfaces are restricted to provide only one functionality. Regardless, it is possible to implement services with more interfaces (i.e. with more functional capabilities), but the interfaces have to provide independent functionality. This allows to add, remove or alter any capability, which is provided by the service, without large modifications in the service specification. This provide better reusability and leads to easy extensibility of modeled services.

7

Conclusion

This paper concerns Service-Oriented Analysis and Design, especially integration between Business Process Modeling and Service Modeling. We outlined a transformation technique that defines how a business process should be transformed into an orchestration of services and how the services should collaborate to fulfill the business goals. The transformation is based on control-flow patterns and is designed in conformity with fundamental SOA principles such as loose coupling, service independence, stateless and reusability. Some of these features are novel and have not been integrated into existing service-oriented modeling methods. The presented ideas are a part of a greater project, which deals with modeling and formal specification of SOA and underlying component-based systems.

Service-Based Realization of Business Processes

101

The approach, which is presented in this paper, is aimed at modeling of highlevel-abstract layers of the SOA hierarchy. The future work will focus on formal description of the proposed transformation and on an integration with formal component models. This allows formal verification of a whole modeled system (e.g. tracing of changes in a business process model to the changes in components’ structure). Furthermore, the formal description of the transformation allows validation of the generated service orchestration. Besides, the ongoing research includes design of additional transformation rules, especially rules for business patterns based on gateways and events, and applying the transformation in a real-world case study.

References 1. Amir, R., Zeid, A.: A UML profile for service oriented architectures. In: OOPSLA 2004: Companion to the 19th Annual ACM SIGPLAN Conference on ObjectOriented Programming Systems, Languages, and Applications, pp. 192–193. ACM, Vancouver (2004) 2. Amsden, J.: Business services modeling: Integrating WebSphere Business Modeler and Rational Software Modeler, http://www.ibm.com/developerworks/ rational/library/05/1227_amsden/ 3. Arsanjani, A.: Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA, http://www.ibm.com/developerworks/ webservices/library/ws-soa-design1/ 4. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River (2005) 5. Inaganti, S., Behara, G.K.: Service Identification: BPM and SOA Handshake. BPTrends (March 2007), http://www.bptrends.com/publicationfiles/ THREE%2003-07-ART-BPMandSOAHandshake-InagantiBehara-Final.pdf 6. Johnston, S.: UML 2.0 Profile for Software Services, http://www.ibm.com/ developerworks/rational/library/05/419_soa/ 7. Murzek, M., Kramler, G.: Business Process Model Transformation Issues - The Top 7 Adversaries Encountered at Defining Model Transformations. In: Proceedings of the Ninth International Conference on Enterprise Information Systems, pp. 144– 151. INSTICC, Paphos (2007) 8. Object Management Group: UML Superstructure Specification, version 2.0, http://www.omg.org/cgi-bin/doc?formal/05-07-04 9. Object Management Group: Business Process Modeling Notation (BPMN) Specification, http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPM %201-0%20Spec%2006-02-01.pdf 10. Object Management Group: UML Profile and Metamodel for Services (UPMS), Request For Proposal, http://www.omg.org/docs/soa/06-09-09.pdf 11. Ortiz, G., Hernandez, J.: Toward UML Profiles for Web Services and their ExtraFunctional Properties. In: IEEE International Conference on Web Services (ICWS 2006), pp. 889–892. IEEE Computer Society, Chicago (2006) 12. Rychly, M., Weiss, P.: Modeling Of Service Oriented Architecture: From Business Process To Service Realisation. In: ENASE 2008 Third International Conference on Evaluation of Novel Approaches to Software Engineering Proceedings, pp. 140–146. INSTICC, Funchal (2008)

102

P. Weiss

13. van der Aalst, W.M.P., Barros, A.P., ter Hofstede, A.H.M., Kiepuszewski, B.: Advanced Workflow Patterns. In: Scheuermann, P., Etzion, O. (eds.) CoopIS 2000. LNCS, vol. 1901, pp. 18–29. Springer, Heidelberg (2000) 14. Weiss, P.: Using UML 2.0 in Service-Oriented Analysis and Design. In: Proceedings of the 12th Conference and Competition STUDENT EEICT 2006, vol. 4, pp. 420– 424. Faculty of Information Technology BUT, Brno (2006) 15. Weiss, P., Zendulka, J.: Modeling of Services and Service Collaboration in UML 2.0. In: Information Systems and Formal Models, pp. 29–36. Faculty of Philosophy and Science in Opava, Silesian University in Opava, Opava (2007) 16. White, S.: Process Modeling Notations and Workflow Patterns. BPTrends (February 2008), http://www.bptrends.com/deliver file.cfm?fileType=publication &fileName=03%2D04%20WP%20Notations%20and%20Workflow%20Patterns%20%2D %20White%2Epdf 17. Wohed, P., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M., Russel, N.: Pattern-based Analysis of BPMN - An extensive evaluation of the Controlflow, the Data and the Resource Perspectives (revised version), http://www. workflowpatterns.com/documentation/index.php

SMA—The Smyle Modeling Approach Benedikt Bollig1 , Joost-Pieter Katoen2 , Carsten Kern2 , and Martin Leucker3 1 2

LSV, ENS Cachan, CNRS RWTH Aachen University 3

TU M¨unchen

Abstract. This paper introduces the model-based software development methodology SMA—the Smyle Modeling Approach—which is centered around Smyle, a dedicated learning procedure to support engineers to interactively obtain design models from requirements, characterized as either being desired (positive) or unwanted (negative) system behavior. The learning approach is complemented by scenario patterns where the engineer can specify clearly desired or unwanted behavior. This way, user interaction is reduced to the interesting scenarios limiting the design effort considerably. In SMA, the learning phase is complemented by an effective analysis phase that allows for detecting design flaws at an early design stage. This paper describes the approach and reports on first practical experiences. Keywords: Requirements elicitation, design model, learning, software engineering lifecycle, Message Sequence Charts, UML.

1 Introduction To put it bluntly, software engineering—under the assumption that a requirements acquisition has taken place—amounts to bridging the gap between requirements, typically stated in natural language, and a piece of software. To ease this step, in model-driven design (like MDA), architecture-independent design models are introduced as intermediary between requirement specifications and concrete implementations. These design models typically describe the control flow, basic modules or components, and their interaction. Design models are then refined towards executable code typically using several design steps where system details are incorporated progressively. Correctness of these design steps may be checked using, e.g., model checking or deductive techniques. Problems in software engineering cycles occur if, e.g., the number of requirements is abundant, they are ambiguous, contradictory, and change over time. Evolving requirements may be due to changing user requirements or to anomalous system behavior detected at later design stages and thus occur at all stages of the development process. This paper presents a novel software engineering lifecycle model based on a new approach towards requirement specification and high-level design. It is tailored to the development of communicating distributed systems whose behavior can be specified using sequence diagrams exemplifying either desired or undesired system runs. A widespread notation for sequence diagrams is that of message sequence charts (MSCs). They have 

This work is partially supported by EGIDE/DAAD (Procope 2008), DOTS (ANR-06-SETIN003), and P2R MODISTECOVER.

Z. Huzar et al. (Eds.): CEE-SET 2008, LNCS 4980, pp. 103–117, 2011. c IFIP International Federation for Information Processing 2011 

104

B. Bollig et al.

been adopted by the UML, are standardized by the ITU [22], and are part of several requirements elicitation techniques such as CREWS [26]. At the heart of our approach—called the Smyle Modeling Approach (SMA)— dedicated learning techniques support the engineer to interactively obtain implementation-independent design models from MSCs exemplifying the system’s behavior. These techniques are implemented in the tool Smyle (Synthesizing models by learning from examples, cf. [5]). The incremental learning approach allows to gradually develop, refine, and complete requirements, and supports evolving requirements in a natural manner, rather than requiring a full-fledged set of requirements up front. Importantly, Smyle does not only rely on given system behaviors but progressively asks the engineer to classify certain corner cases as either desired or undesired behavior, whenever the so-far provided examples do not allow to uniquely determine a (minimal) system model. As abstract design models, Smyle synthesizes distributed finite-state automata (referred to as communicating finite-state machines, or CFMs for short) [5]. This model is implementation-independent and describes the local control flow as finite automata which communicate via unbounded order-preserving channels. The learning approach is complemented by so-called scenario patterns where the engineer can specify clearly desired or unwanted behavior via a dedicated formula editor. This way, user interaction is reduced to the interesting scenarios limiting the design effort considerably. Once an initial high-level design has been obtained by learning, SMA suggests an intensive analysis of the obtained model, first by comprehensive simulation and second by checking elementary correctness properties of the CFM, for example by means of model checking or dedicated analysis algorithms [6]. This allows for an early detection of design flaws. In case of a flaw, i.e., some observed behavior should be ruled out or some expected behavior cannot be realized by the current model, the learning phase can be continued with the corresponding scenarios yielding an adapted design model now reflecting the expected behavior for the given scenarios. A satisfactory high-level design may subsequently be refined or translated into, e.g., Stateflow diagrams [17] from which executable code is automatically generated using tools as Matlab/Simulink. The final stage of SMA is a model-based testing phase [10] in which it is checked whether the software conforms to the high-level design description. The MSCs used for formalizing requirements now serve as abstract test cases. Moreover, supplementary test cases are generated in an automated way. This systematic on-the-fly test procedure is supported by tools such as TorX and TGV [2] that can easily be plugged in into our design cycle. Again, any test failure can be described by MSCs which may be fed back to the learning phase. Related work. To our best knowledge there is no related work on defining lifecycle models based on learning techniques. However, several approaches for synthesizing models based on scenarios are known. In [32,31], Uchitel et al. recommend the use of high-level MSCs (HMSCs) as input for model synthesis. High-level MSCs aim at specifying the overall system behavior, yet are hard to adapt when unwanted behavior has to be removed or wanted behavior has to be defined. The same problem arises for Live Sequence Charts or related formalisms [13,19,8]. In general, whenever modeling the overall global system behavior, a modification due to changing requirements is cumbersome and error prone.

SMA—The Smyle Modeling Approach

105

The approaches taken in [25] and [12] are, similarly as Smyle, based on learning techniques. The general advantage of learning techniques is that changing requirements can be incorporated into the learning process. However, the algorithms of [25] and [12] both have the drawback that the resulting design model does not necessarily conform to the given examples and requires that unwanted “[...] implied scenarios should be detected and excluded” [12], manually, while Smyle does conform to the given examples. A very interesting prospect is described in [18] where Harel presents his ideas and dreams about scenario-based programming and proposes to use learning techniques for system synthesis. In his vision “[the] programmer teaches and guides the computer to get to know about the system’s intended behavior [...]”—just as it is our intention. An extended journal version of this paper will be available as [7]. Outline. In Section 2 the ingredients for our learning approach are described and complemented by a theoretical result on its feasibility. Section 3 describes SMA in detail and compares it to traditional and modern software engineering lifecycle models. In Section 4 we apply SMA gradually to a simple example, followed by insights on an industrial case study in Section 5.

2 Ingredients of the SMA We now recall message sequence charts (MSCs), communicating finite-state machines, describe the gist of Smyle and present a logic for specifying sets of MSCs. 2.1 Message Sequence Charts Message Sequence Charts (MSCs) are an ITU standardized notation [22] for describing message exchange between concurrent processes. An MSC depicts a single partially ordered execution sequence of a system. It defines a collection of processes, which are drawn as vertical lines and interpreted as top-down time axes. Labeled vertical arrows represent message exchanges, cf. Figure 1 (a). An MSC can be understood as a graph whose nodes represent communication actions, e.g., the graph in Figure 1 (b) represents the MSC of Figure 1 (a). A node or event represents the communication action indicated by its label, where, e.g., 1!2(a) stands

1

2

c b c

a

3

1!2(a) u

msg

2?3(c)

proc

msg

1!3(b)

msg

2?3(c)

msg

2?1(a)

(b) Fig. 1. An MSC (a) and its graph (b)

3?1(b) proc

proc

(a)

3!2(c) proc

proc

v 3!2(c)

106

B. Bollig et al.

for sending a message a from 1 to 2, whereas 2?1(a) is the complementary action of receiving a from 1 at process 2. The edges reflect causal dependencies between events. An edge can be of two types: it is either a process edge (proc), describing progress of one particular process, or a message edge (msg), relating a send with its corresponding receive event. This graph can be represented as a partial order of communication events. In this work we abstract from several features provided by the standard. Many of them (e.g., local actions, co-regions, etc.) can be easily included. Some of them, however, are excluded on purpose: loops and alternatives are not allowed as single executions are to be specified by MSCs. Note that, in correspondence to the ITU standard but in contrast to most works on learning MSCs, we consider the communication of an MSC to be asynchronous meaning that sending and receiving of a message may be delayed. A (finite or infinite) set of MSCs, which we call an MSC language, may represent a system in the sense that it contains all possible scenarios that the system may exhibit. MSC languages can be characterized and represented in many ways. Here, the notion of a regular MSC language is of particular interest, as it comprises languages that are learnable . Regularity of MSC languages is based on linearizations: A linearization of an MSC M is a total ordering of its events that does not contradict the transitive closure of the edge relation. Any linearization can be represented as a word over the set of communication actions. Two sample linearizations of the MSC from Figure 1 are l1 = 1!2(a)3!2(c)2?3(c)1!3(b)3?1(b)3!2(c)2?3(c)2?1(a) and l2 = 3!2(c) 2?3(c) 1!2(a) 1!3(b) 3?1(b) 3!2(c) 2?3(c) 2?1(a). Let Lin(M  ) denote the set of linearizations of M and, for set  of MSCs, let Lin() denote M ∈ Lin(M ). 2.2 Communicating Finite-State Machines Regular MSC languages can be naturally and effectively implemented in terms of communicating finite-state machines (CFMs) [9]. CFMs constitute an appropriate automaton model for distributed systems where processes are represented as finite-state automata that can send messages to one another through reliable FIFO channels. We omit a formal definition of CFMs and instead refer to the example depicted in Figure 2 illustrating the Alternating Bit Protocol [24,30]. There, a producer process (p) and a consumer process (c) exchange messages from {0, 1, a}. Transitions are labeled with communication actions such as p!c(0), p?c(a), etc. (abbreviated by !0, ?a, and so on). For a concise description of this protocol, see Section 4. A CFM accepts a set of MSCs in a natural manner. For example, the language of the CFM from Figure 2 contains the MSCs depicted in Figure 4. Using CFMs, we account for the asynchronous communication behavior whereas usually other approaches use synchronous communication. This complicates the underlying theory of learning procedures but results in a model that exactly does what the user expects and does not represent an over-approximation. The formal justification of using regular MSC languages is given by the following theorem, which states that a set of MSCs is implementable as a CFM if its set of linearizations is regular, or if it can be represented by a regular set of linearizations. Theorem 1 ([20,15]). Let  be an MSC language. There is a CFM accepting precisely the MSCs from , if one of the following holds:

SMA—The Smyle Modeling Approach

?a !0

!1 !1

!0

!0

!a

?1

producer p

?1 ?1

?0 ?0

?a

107

!a

?0

consumer c Fig. 2. Example CFM

1. The set Lin() is a regular set of words.

2. There is a channel bound B and a regular subset L of Lin() such that (i) any MSC from  exhibits a linearization that does not exceed B, and (ii) L contains precisely the linearizations from Lin() that do not exceed B. If the regular languages are given as finite automata, we can compute a corresponding CFM effectively. 2.3 The Gist of Smyle Smyle is the learning procedure underlying SMA and has recently been described in [5]. As input, Smyle is given a set + of positive scenarios which are desired executions of the system to be and a set − of negative scenarios which should not be observed as system executions. If the given examples do not indicate a single conforming model, Smyle saturates both sets by asking further queries which are successively presented to the user who in turn has to classify each of them as either positive or negative resulting ¯ + and  ¯ − . Otherwise, a minimal deterministic finite automaton and a correspondin  ¯ + and rejecting those of  ¯ − are computed. If a ing CFM accepting the MSCs of  subsequent analysis of the obtained CFM shows that it does not conform to the user’s ¯ + or  ¯ − and intention, it can be refined by providing further examples to be added to  reinvoking the learning procedure. This process eventually converges to any intended CFM [5]. At first sight, one might think that inconsistencies could be introduced by the classifications of the presented MSCs. However, this is not possible due to the simple nature of MSCs: We do not allow branching, if-then-else or loop constructs. Thus they cannot overlap and generate inconsistencies. Note moreover that the learning algorithm is deterministic in the following sense: For every (saturated) set of examples, the learning algorithm computes a unique CFM. This allows, within SMA, to rely only on all classified MSCs within a long-term project and to resume learning whenever new requirements arise. Moreover, reclassification in case of user errors is likewise simple. An important aspect that distinguishes Smyle from others [25,12] is that the resulting CFM is consistent with the set of MSCs that served as input. Other approaches project their learning result onto the processes involved, accepting that the resulting system is a (coarse) over-approximation.

108

B. Bollig et al.

2.4 MSC Patterns In order to significantly reduce the number of scenarios the user has to classify during a learning phase, it is worthwhile to consider a formalism where (un)desired behavior can a priori be specified in terms of logical formulas. Due to space constraints we only give a superficial description of how to apply such a logic within the SMA. A more sophisticated introduction can be found in [7]. The logic we employ will be used as follows: positive and negative sets of formulas Φ+ and Φ− are input by the user, either directly or by annotating MSCs. An example for a negative statement would be, say, “there are two receipts of the same message in a row”. An annotated MSC for this example formula is given in Figure 6 (c). Then, the learning algorithm can efficiently check for all formulas ϕ+ ∈ Φ+ , ϕ− ∈ Φ− and unclassified MSCs M whether M |= ϕ+ or M |= ϕ− . If so, then the set of negative samples is updated to {M } ∪ − and otherwise the question is passed to the user.

3 The Smyle Modeling Approach It is common knowledge [14] that traditional engineering lifecycle models like the waterfall model [28,29,27,16] or the V-model [27,29] suffer from some severe deficiencies, despite their wide use in today’s software development. One of the problems is that both models assume (implicitly) that a complete set of requirements can be formulated at the beginning of the lifecycle. Although in both approaches it is possible to revisit a previously passed phase, this is considered a backwards step involving time-consuming reformulation of documents, models, or code produced, causing high additional costs. The nature of a typical software engineering project is, however, that requirements are usually incomplete, often contradicting, and frequently changing. A high-level design, on the other hand, is typically a complete and consistent model that is expected to conform to the requirements. Thus, especially the step from requirements to a highlevel design is a major challenge: The incomplete set of requirements has to be made complete and inconsistencies have to be eliminated. An impressive example for inconsistencies in industrial-size applications is given by Holzmann [21] where for the design R and implementation of a part of Signaling System 7 in the 5ESSswitching system (the ISDN User-Part protocol defined by the CCITT) “almost 55% of all requirements from the original design requirements [...] were proven to be logically inconsistent [...]”. Moreover, also later stages of the development process often require additional modifications of requirements and the corresponding high-level design, either due to changing user requirements or due to unforeseen technical difficulties. Thus, a lifecycle model should support an easy adaptation of requirements and its conforming design model also at later stages. The SMA is a new software engineering lifecycle model that addresses these goals. 3.1 A Bird’s-eye View on SMA The Smyle Modeling Approach (SMA) is a software engineering lifecycle model tailored to communicating distributed systems. A prerequisite is, however, that the participating units (processes) and their communication actions can be fixed in the first steps of the

SMA—The Smyle Modeling Approach

109

development process, before actually deriving a design model. Requirements for the behavior of the involved processes, however, may be given vaguely and incomplete first but are made precise within the process. While clearly not every development project fits these needs, a considerable amount of systems especially in the automotive domain do. Within SMA, our goal is to round-off requirements, remove inconsistencies and to provide methods