Service-oriented architectures (SOA) are deeply changing the landscape of software system development. Mechanisms such as automatic service discovery, ...
Discovery of SOA Patterns via Model Checking Massimiliano Di Penta, Antonella Santone, and Maria Luisa Villani {dipenta, santone, villani}@unisannio.it RCOST University of Sannio Via Traiano, 82100 Benevento, Italy
ABSTRACT
a workflow) and dispatch them to one of many equivalent concrete services that implement the same piece of functionality. For example, a workflow can request a image processing service, for which there are many equivalent services available.
Design pattern recovery has been proved to be an useful mechanism to assess the quality of object-oriented systems, to facilitate their comprehension, and to help identifying reusable assets. The diffusion of Service Oriented Architectures (SOA) is fostering the introduction of new patterns, realizing recurring mechanisms that service-oriented systems often realize. Examples are proxies used to enable dynamic binding or to ensure fault tolerance, service compositions, and loggers used for monitoring purposes. This paper describes how SOA patterns can be identified by analyzing SOAP messages collected by monitoring a service oriented system. Namely, the paper presents a model checking-based approach where patterns, described by parametric selective mu-calculus logic formulae, are verified on a synthetized model of the system.
2. similarly, a proxy service can be used to implement fault tolerance, i.e., the same request can be dispatched to multiple services realizing the same piece of functionality. When all services have performed their task, the correct results will be determined based on a voting mechanism. 3. a service can receive a request and realize it by coordinating invocations to other services; 4. a service can act as a data logger, flow logger or state logger, i.e., dispatching a request to one or more services and, at the same time, keeping track of monitoring data, or of the state of a service composition it is coordinating.
Categories and Subject Descriptors D.2 [Software Engineering]
General Terms Design
A complete description of service engineering patterns is reported in a paper by Milanovic [16]. Identifying these patterns in existing service oriented systems would be beneficial for a number of purposes. First, it helps supporting to better understand the behavior of the service oriented system, by highlighting clusters of services that interact to achieve a specific objective. Second, it helps to identify reusable assets: for example, once identified, a proxy that enacts dynamic binding or fault-tolerance can be reused in other workflows requiring the same mechanism. Third, the proper usage of specific interaction patterns to realize some specific features can be a quality indicator for the system. In the past, the same motivations held for design pattern recovery from object-oriented systems [2, 7, 12, 13, 15, 21].
Keywords Pattern discovery, Comprehension of service-oriented systems, SOA patterns, model checking
1.
INTRODUCTION
Service-oriented architectures (SOA) are deeply changing the landscape of software system development. Mechanisms such as automatic service discovery, dynamic binding and self-healing represent some of the most interesting features SOA can provide. To enable these mechanisms, system integrators often use recurring composition patterns. For example:
This paper proposes an approach that uses model-checking to detect design patterns by analyzing formulae abstracted from Simple Object Access Protocol (SOAP) messages exchanged between different services involved in the system. Differently from traditional software systems, where a combination of static and dynamic analysis can be used to detect design patterns [13], in the context of service oriented architectures pattern detection can only rely on observing SOAP messages, while the source code is not available. In other words, in this context patterns are identified by a sequence of service interactions, while the system structure is not visible and, above all, dynamically changing. For this reason,
1. dynamic binding is enacted by means of proxy services that receives requests from a service composition (e.g., Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. W-SOSWE’07, September 3, 2007, Dubrovnik, Croatia Copyright 2007 ACM ISBN 978-1-59593-723-0/07/09...$5.00
8
even patterns having a similar role of gang-of-four structural patterns [10], such as Adapter and Proxy, cannot be identified by matching a structure (as it was done by Antoniol et al. [2])), while they can be detected by analyzing the SOAP messages exchanged between the service composition, the Proxy/Adapter service and the services to which the Proxy or Adapter dispach the request made by the composition.
true (list of services) Trace-based representation of the system
CCS Model* Model Checker pattern1 (parametric formula)
The paper is organized as follows. Section 2 reports, for completeness’ sake, some background notions on model checking. Section 3 describes the proposed pattern detection approach, while Section 4 shows results obtained in applying the proposed approach to detect proxies from an existing service-oriented system. After a discussion of related work in Section 5, Section 6 concludes the paper.
2.
trace2CCS
… patternN (parametric formula)
instantiation
… instantiation false
Figure 1: An overview of our approach
A PRIMER ON MODEL-CHECKING
hKiR φ is satisfied by a state which can evolve to a state obeying φ by performing a sequence of actions not belonging to R ∪ K followed by an action in K.
In the model checking framework, systems are modeled by transition systems and requirements are expressed by formulae in temporal logic. A model checker accepts two inputs, a transition system and a temporal formula, and returns “true” if the system satisfies the formula, otherwise it returns a counterexample that can be used to pinpoint the source of the error.
As in the standard mu-calculus, µZ.φ is the least fix-point of the recursive equation Z = φ, while νZ.φ is the greatest one. Let us express some properties using the selective mucalculus formulae: ”if either an action c or an action d has not been executed, neither a nor b can be performed”: [a, b]{c,d} ff; ”for each action a, preceded by any action, it is possible to perform an action b without executing the actions d and c”: [a]∅ hbi{d,c} tt.
To express systems we use the Calculus of Communicating Systems (CCS) [17]. The syntax of processes is the following: p ::= nil | α.p | p + p | p|p | p\L | p[f ] | x where α ranges over a finite set of actions A. The action τ ∈ A is called internal action. The set L ranges over sets of visible actions (A − {τ }), f ranges over functions from actions to actions, while x ranges over a set of constant names: def each constant x is defined by a constant definition x = p.
3.
THE APPROACH
Given a set of systems logs and a set of patterns, the aim is to answer the following questions: 1. whether the system contains one or more of the considered patterns (if yes, which ones);
The process nil can perform no actions. The process α.p can perform the action α and thereby become the process p. The process p + q can behave either as p or as q. The operator | expresses parallel composition. The operator \ expresses the restriction of actions, while he operator [f ] expresses the re-labeling of actions. Finally, a constant x def behaves as p if x = p.
2. for each pattern detected, match the pattern roles with the services making it. The approach, illustrated in Figure 1, is outlined through the following steps.
In this paper, we use the term trace to refer to a sequence of actions. To express requirements we use the selective mucalculus logic [4], a Branching Temporal Logic (BTL). It is a variant of mu-calculus [20] and differs from it in the definition of the modal operators. The syntax of the selective mu-calculus is the following, where K and R range over sets of actions, while Z ranges over a set of variables:
The satisfaction of a formula φ by a state s of a transition system, written s |= φ, is defined as follows: each state satisfies tt and no state satisfies ff; a state satisfies φ1 ∨ φ2 (φ1 ∧ φ2 ) if it satisfies φ1 or (and) φ2 . [K]R φ and hKiR φ are the selective modal operators:
Representation of the system under study. Each system under study must be represented as a set of traces. In order to obtain such representation, SOAP messages directed to, and issued by, all the services used by the system can be intercepted throughout execution by some monitoring mechanism. For this, we used the SOAP monitor APIs provided by the Apache Axis SOAP implementation server. The following data can be recorded for each SOAP communication: the time-stamp of the message (i.e., the date/time the message was sent), the service caller, the service receiver, the type of the message (i.e., whether request or response), the operation invoked, and the list of the input/output values. Thus, full execution logs of the system can be reconstructed upon this data (we assume all system executions to be sequential).
[K]R φ is satisfied by a state which, for every performance of a sequence of actions not belonging to R ∪ K, followed by an action in K, evolves in a state obeying to φ.
Two types of CCS traces are retrieved from each log, that we call valued and abstract, according to whether the input/output data values of the SOAP messages are accounted
φ ::= tt|ff|Z|φ ∨ φ|φ ∧ φ| [K]R φ| hKiR φ|νZ.φ|µZ.φ.
9
for in the names of the actions of the traces to be built, or they are abstract away. Indeed, in our approach, we first verify the abstract model of the system to detect possible patterns (this allows us both to work on a reduced model and to perform a restricted number of verifications), then a second round of verifications on the valued model can be eventually performed to filter out false positive results, in case these data values are relevant in the definition of the pattern. Actions of the abstract CCS traces are named as follows: msgT ype ServSend ServReceiv Oper,
or even model checking can be used to restrict the set of possible formula instantiations (and so the number of verifications to perform). For example, we used model checking to identify possible candidates for the proxy pattern, by verifying the existence of at least one sequence of actions, containing one incoming request message to a service S and one outgoing request message from S, and dually for the response. Hence, by means of a model checker (e.g., [5]), we verify whether p satisfies the AND of all the instantiated formulae. In case of a TRUE answer by the model checker, the result of such verification process will be a list of services matched with the roles of the pattern considered. If the answer by the model checker is FALSE, the model checking phase can be re-started considering a more relaxed definition of the pattern (hence taking a different formula template) to understand whether that pattern is present at higher level. A simple example is given by the proxy pattern, whose strict definition does not allow to perform interface adaptation functions, which, instead, is of common use [9].
(1)
where: msgType is equal to req for request messages and resp for reponse message; ServSender is the name of the service issuing the SOAP message, and ServReceiver the name of the message receiver service; Oper is the operation name. For valued traces, the action names as in (1) are extended with the list of the parameters values. Here is an example of a valued action: req ImgP roc ImgElabServ scale photo.BM P, 500
(2)
We present in details the last two steps of our approach.
retrieved from a SOAP communication where a service-centric application ImgProc, invokes a scale operation of the service ImgElabServ on the image photo.BMP, whose final size has to be of 500 KB.
3.1
Construction of a high level model
We define a general syntactic transformation function T which converts a set of traces into a CCS process by means of the auxiliary functions defined below.
Construction of a high level model. A traces-to-CCS operator T has been defined to build a CCS model p from the set of traces T , obtained in the previous step. This model synthesizes all the services interactions previously logged, and can be extended when new logs are available. Of course, as our model checking approach to pattern detection is based on this model, the result will be relative to it, namely, patterns detected as such on a model constructed at some stage, could be discarded after further executions of the system. For a service-centric system, this can be due to several factors:
Definition 3.1. Let T be a set of traces. First(T ) = {α | α.t0 ∈ T } del(T ) = {t|α.t ∈ T }. F irst(T ) denotes the set of the first actions of all the traces in T . When F irst(T ) = {α}, First(T ) returns the single action α. The function del eliminates the first action from all the traces in T . Definition 3.2 (split). Let T be a set of traces. The function split divides T into n ≥ 1 disjoint sets T1 , . . . , Tn such that:
1. the coverage capabilities of the input sets that produced the logs; 2. the evolution of the system with respect to the services statically bound to it, i.e., through a deploy update;
• T = T1 ∪ · · · ∪ Tn ;
3. the dynamic binding capabilities that the system may probably exploit, e.g., the behavior of a system may be conditioned by the availability of one or more other services that can be used to fulfill some functionality.
• Ti ∩ Tj = ∅, ∀i, j ∈ [1..n] with i 6= j; and • ∀i ∈ [1..n], t1 , t2 ∈ Ti iff F irst({t1 }) = F irst({t2 }). Intuitively, split(T ) divides a set of traces T into n ≥ 1 distinct sub-sets such that traces having the same first action are put in the same sub-set. For example, given: T = {a.b.c.nil, a.b.d.nil, c.b.d.nil, d.a.b.nil, d.b.e.nil} the function split(T ) produces the following three sub-sets:
To this aim, automatic test data generation (e.g., based on search-based optimization techniques [8]) can be used to obtain a representative set of traces leading to more accurate results.
{a.b.c.nil, a.b.d.nil} {c.b.d.nil} {d.a.b.nil, d.b.e.nil}
Pattern detection via model checking. We have formalized each pattern (and each pattern variation) with a (parametric) selective mu-calculus formula, representing its behavior, which needs to be instantiated with actions belonging to the alphabet of the process p, obtained in the previous step. To avoid considering all the actions of p and all the possible correspondences of those actions with the parameters of the formula, based on the pattern, heuristics
Definition 3.3. Let T be a set of traces. First calculate split(T ). Suppose that split(T ) = {T1 , . . . , Tn }. The tracesto-CCS operator T is defined as: (
T (T ) =
nil
Pn i=1
10
if T = ∅ 0
T (Ti ) otherwise
where T 0 (T ) applies to the set of traces T such that all traces in T have the same first action. The definition of T 0 (T ) is the following: (
T 0 (T ) =
α.(τ.nil + T (del(T )))
Pn
i=1
The formula is: ϕ = F cp
F irst(T ).T (del(T ))
otherwise
req ps∈F W req f rom P
G ps
resp_pc
req f rom P }
[req ps]{Req
ff∧
to P }
(b) G ps
(c)
eventually(resp sp)∧
(d)
[resp pc]{resp sp} ff∧
(e)
[F W req f rom P ]{Resp to P } ff∧
(f )
[resp sp]∅ G ps G0 ps
=
eventually(resp pc)∧ [F W req f rom P ]{Req
(g) to P }
ff
Given a set of action K, the formula eventually(K) = µZ. h−iA tt ∧ [−K]A Z expresses the property: ”eventually an action in K happens”. Informally, the formula ϕ means that, if a client C makes a request to the proxy P , namely req cp, we move to a state (corresponding to the formula F cp), where a request to P has been executed. Here the proxy cannot perform any other task except forwarding the request to a selected service; more precisely, in this state: • eventually P forwards the request (a); and
req_ps
P
(a)
0
Pattern detection via model checking
C
=
[req cp]∅ F cp, where
eventually(F W req f rom P )∧ V
Without loss of generality, from now on we restrict our focus on the proxy pattern, which is one of the most used architectural patterns of service-centric systems. In particular, here we say that a service is a (simple) proxy if, acting between a client and another service that will really fulfill the client request, performs some tasks before, which do not involve other external services, e.g., controlling what actual service to invoke [9]. In this definition, we allow the operation name of the proxy service to be different from that of the final service. req_cp
req cp∈Req to P
[resp pc, Resp to P ]{F W
if {α.t, α} ⊆ T
By using T , events with the same name are considered as a single action in the CCS process; moreover branching in a process is possible only if we find two different events, in different traces, after events with the same name. To better explain this, consider the following set of traces T = {a.b.nil, a.b.c.nil, d.a.nil}. The CCS process obtained by applying the function T is a.(b.(τ.nil + c.nil)) + d.a.nil. It is easy to show that the constructed CCS process generates exactly the traces in T .
3.2
=
V
• before forwarding the request to a service, the proxy neither can forward the response to the client (i.e. action resp pc) nor can receive a response (b); and
S
• when P forwards the request to a service (action req ps), not preceded by another request to P , we move to a state corresponding to the formula G ps (c).
resp_ps
Figure 2: The proxy pattern automaton
G ps represents the situation in which the proxy has forwarded the request to a service and it is just waiting for the response. More precisely:
Figure 2 depicts this pattern, which can be read as follows: (1) a client C (which may also be a service) sends its request to the proxy P (action req cp); (2) the proxy forwards the request to a service S (action req ps); (3) the service sends a response to the proxy (action resp ps); and (4) the proxy forwards the response to the client (action resp pc).
• eventually the service sends a response to P (i.e. action resp sp)(d); and • the proxy cannot forward to the client the response (action resp pc) before the service has not responded to P (action resp sp)(e); and
The automaton in Figure 2 expresses the only allowed sequences of actions, and this can be formalized by a parametric selective mu-calculus formula, defined below. The parameters of the formula are the following set of actions:
• the proxy cannot forward any other request if it has not received a response from a service (f ); and
Req to P (over which req cp ranges): all requests from clients to the proxy P ;
• when the service sends a response to P (action resp sp) we move to a state (corresponding to the formula G0 ps).
• F W req f rom P (over which req ps ranges): all forwarded requests from the proxy P to services;
G0 ps represents the situation in which the service has sent the response to the proxy and now the proxy must only forward the response to the client. More precisely:
• Resp to P (over which resp sp ranges): all responses from services to the proxy P ; • F W resp f rom P ( over which reap pc ranges): all forwarded responses from the proxy P to clients.
• eventually the proxy forwards the response to the client (action resp pc) (g) and;
11
(h)
Receive
• the proxy cannot forward other requests if a request to P has not been previously sent (h).
[needRotating]
The last property is to allow interleaving of the proxy-pattern execution with that issued by another client.
checkSize
The behavior of other patterns, as well as variations of the proxy-pattern above, can be similarly expressed. For example, the behavior of a fault-tolerant proxy that is not a simple proxy can be described by enforcing, in the formula above, the existence of a path where every request req cp is concurrently forwarded to more than one service along all paths. We note that this existential property could not be expressed by a Linear Temporal Logic.
rotate
Proxy ImageManipulation
AS2
addConstant
AS3
executeMedian
[add]
I2
I3 Proxy ImageManipulation1
[difference]
I1
I4
executeDifference executeAdd
4.
AS1
C1
AS4
AS5 I5
CASE STUDY
In order to illustrate the approach, we considered a service composition previously developed within a project [9], dealing with service-centric systems engineering. The process, shown in Figure 3, takes as an input one or two images, plus some options. One option is the rotation of one image of a specified degree. If this option is chosen, the system needs to check the size for the other photo (the two photos will be subsequently combined), and this is done in parallel with the rotation operation. Then, other operations are used to make changes to the image basic colors, and then a sum, or a difference (e.g., adding a frame or removing a background) is computed with the second image. Finally, the resulting image is properly scaled. The system was written in WS-BPEL [1], and proxy services were statically bound to the composition in order to exploit the dynamic binding capabilities of the framework. For the proxy services, we used two variations of the pattern, namely the simple proxy described in Section 3 and the fault-tolerant pattern, where the message is concurrently forwarded to several services. The bindings to the fault-tolerant proxy service for some operations were introduced in a second deploy of the same system. In this example, only (synchronous) request/reply communication types were used.
AS6
executeScale
Reply
Figure 3: The system
bound to the operations above, and so, in this case the behavior of the fault tolerance proxy is the same as that of the simple proxy. 3. However, having added three further logs, the resulting LTS model turned out as in Figure 4 (b), where the ProxyImageManipulation1 service for the operation executeAdd, may call more than one service (either concurrently or subsequently) to satisfy the request. Therefore, for that operation the service ProxyImageManipulation1 failed to satisfy the simple proxy formula (the ProxyImageManipulation remained as the only proxy). 4. Finally, we removed the previously added logs to return to point 2 above, and added one log corresponding to the system execution with a different input set (a different format of the photos), and causing the operation executeDifference to be invoked. Although the abstract LTS model of the system did not change with respect to point 2, a second verification of the concrete LTS model (including data), applied to the proxy services detected from the first verification, detected the ProxyImageManipulation1 to fail the property. Indeed, the photos forwarded by ProxyImageManipulation1 after the executeDifference request had a different extension, i.e., JPG rather then BMP. This means that the operation executeDifference of ProxyImageManipulation1 made also other operations on the received input data.
We subsequently run the system several times, and, from the execution logs collected, the formal approach presented in Section 3 was applied in different moments. 1. As a first step, we considered logs of the first deploy of the system (i.e., with static bindings to ProxyImageManipulation and I1) with two input sets, to cover the possible execution traces of the system. With our formal tool, we obtained the LTS model whose fragment is depicted in Figure 4 (a). On that model, the service ProxyImageManipulation was detected to be a proxy. 2. Then, we added two logs of the second deploy of the system (i.e., with static bindings to ProxyImageManipulation, ProxyImageManipulation1 and I1), so that the service ProxyImageManipulation1 was used for the operations executeMedian, scale in both logs, and executeAdd in one log and executeDifference in the second one. From this extended system logs set, the tool detected both services ProxyImageManipulation and ProxyImageManipulation1 to be simple proxies. Indeed, only one candidate service was available to be
5.
RELATED WORK
Techniques for patterns recovery have been mostly developed to apply to software code. Recently, Tsantalis et al. [21] proposed an approach based on similarity scoring between graph vertices. It takes as inputs both the system and the pattern graph (clich´e) and computes similarity scores
12
req_c_i1_checksize req_c_p_rotate
req_c_p1_executeMedian req_c_p_rotate
req_c_p_executeMedian
req_c_i1_checksize req_p_i2_rotate req_p_i1_rotate resp_i2_p_rotate
req_c_p1_executeAdd
resp_i1_c_checksize
req_c_p_executeAdd
resp_c_p_rotate resp_i1_p_rotate
resp_c_p_rotate
req_p1_i1_executeAdd resp_i1_c_checksize
req_p1_i2_executeAdd
resp_i2_p1_executeAdd
resp_i1_p1_executeAdd
req_c_p_executeDifference
req_c_p_executeAdd
resp_p1_c_executeAdd
(a) LTS1
(b) LTS2 Figure 4: The LTS models
between their vertices. Due to the nature of the underlying graph algorithm, this approach is able to recognize not only patterns in their basic form — the ones perfectly matching the clich´e described in the Gamma et al. book [10] — but also modified versions (variants). Several other approaches have been proposed in the past. Some of them relied on static analysis techniques, applying clich´e matching on class diagrams, for example the approach proposed by Kramer et al. [15], by Antoniol et al. [2] or by Gueheneuc et al. [12]. The approach proposed by Costagliola et al. [7] identifies design patterns by visual language parsing, while the approach proposed by Heuzeroth et al. [13] combines static analysis with dynamic analysis on execution traces. In this paper, we propose to express behavioral patterns as temporal-logic formulae, in order to detect patterns by model checking highlevel system models.
original formulas. This makes resolution proofs hard to read and understand, and makes the navigation of the theorem prover through the search space very difficult. Model checking techniques have not this limitation. Arcelli et al. [3] present a prototype tool for EDPs recognition. Yang and Evans [22] present a technique to automatically infer temporal properties from system logs. Property templates in form of string patterns are matched against every single system trace. Thus, their technique can only be used to verify that some events occur according to pre-defined sequences. In Section 3, we argued the need for a BTL to express, for example, the fault-tolerance proxy pattern behavior. Thus, such patterns cannot be verified on every single trace. Cook and Wolf [6] present a statistic-based technique to infer a Finite State Machine model of a system, from an analysis of a sequence of events captured during execution. Their model can be bigger than the sequence of the logged events (and the system model itself), hence formulae satisfied by the execution trace and/or by the system implementation might not be so by that model. A similar problem is tackled by Motahari Nezhad et al. [18] to discover web service interaction protocols from imperfect logs.
A theorem-proving based approach to automated design pattern detection from source code is presented by Smith and Stotts [19]. Elemental design patterns (EDP) are defined, and a formal language is introduced to describe both the design patterns and the system under consideration. However, the paper does not specify which heuristic is used to combine the existing predicates, and in case no heuristic is applied, the computationally complexity of examining all the possible combinations can be prohibitive. Furthermore, resolution based theorem provers work with normal forms of formulas which are not exactly logically equivalent to the
6.
CONCLUSIONS
We presented a model checking-based approach to detect architectural patterns in service-centric systems. Each pattern
13
(and pattern variation) is described by a parametric selective mu-calculus logic, and verification is made on a model of the system, which can be retrieved either from the code (see, for example, Gradara et al. [11] and Koshkina and van Breugel [14]) or from a set of system logs. In the latter case, we showed a method to extract execution traces from SOAP communications, captured by some monitoring mechanism, and synthetize them in a CCS process. One limitation of the current method is that it is not able to detect concurrency of executions of the same pattern, that is, if a proxy service operation is concurrently invoked by the same client, and with the same input data, the proxy-formula we have given might fail. This problem would not exist if we had a CCS process specifying that concurrency, as in the case of the process constructed from the system code or workflow. As a future work, we intend to investigate techniques to infer concurrent CCS process descriptions from system execution traces. Furthermore, we intend to experimentally compare — in the context of SOA interaction patterns and gang-of-four behavioral patterns, where structural matching does not suffice — our approach with other approaches such as that proposed by Tsantalis et al. [21].
7.
[9]
[10]
[11]
[12]
[13]
ACKNOWLEDGMENTS
This work is partially funded by the European Commission VI Framework IP Project SeCSE (Service Centric System Engineering) (http://secse.eng.it), Contract No. 511680.
8.
[14]
REFERENCES
[15]
[1] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, S. T. D. Smith, I. Trickovic, and S. Weerawarana. Business process execution language for web services. http://www-106.ibm.com/developerworks/webservices/ library/ws-bpel/. [2] G. Antoniol, G. Casazza, M. Di Penta, and R. Fiutem. Object-oriented design patterns recovery. Journal of Systems and Software, 59(2):181–196, 2001. [3] F. Arcelli, S. Masiero, and C. Raibulet. Elemental Design Patterns Recognition in Java. In STEP ’05: Proc. of the 13th IEEE Int. Workshop on Software Technology and Engineering Practice, pages 196–205, Washington, DC, USA, 2005. [4] R. Barbuti, N. de Francesco, A. Santone, and G. Vaglini. Selective mu-calculus and formula-based equivalence of transition systems. J. Comput. Syst. Sci., 59(3):537–556, 1999. [5] R. Cleaveland and S. Sims. The NCSU Concurrency Workbench. In CAV ’96: Proc. of the 8th Int. Conference on Computer Aided Verification, pages 394–397, London, UK, 1996. Springer-Verlag. [6] J. E. Cook and A. L. Wolf. Discovering models of software processes from event-based data. ACM Trans. Softw. Eng. Methodol., 7(3):215–249, 1998. [7] G. Costagliola, A. De Lucia, V. Deufemia, C. Gravino, and M. Risi. Design pattern recovery by visual language parsing. In 9th European Conference on Software Maintenance and Reengineering (CSMR 2005), 21-23 March 2005, Manchester, UK, pages 102–111, 2005. [8] M. Di Penta, G. Canfora, M. Bruno, G. Esposito, and V. Mazza. Search-based testing of Service Level
[16]
[17] [18]
[19]
[20]
[21]
[22]
14
Agreements. In Proc. of Genetic and Evolutionary Computation Conference (GECCO 2007), London, UK, July 2007. M. Di Penta, R. Esposito, M. L. Villani, R. Codato, M. Colombo, and E. Di Nitto. WS Binder: a framework to enable dynamic binding of composite web services. In IWSOSE ’06: Proc. of the 2006 international workshop on Service-oriented software engineering, pages 74–80. ACM Press, 2006. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley, 1995. S. Gradara, A. Santone, and M. L. Villani. Using heuristic search for finding deadlocks in concurrent systems. Inf. Comput., 202(2):191–226, 2005. Y.-G. Gu´eh´eneuc, H. A. Sahraoui, and F. Zaidi. Fingerprinting design patterns. In 11th Working Conference on Reverse Engineering (WCRE 2004), 8-12 November 2004, Delft, The Netherlands, pages 172–181, 2004. D. Heuzeroth, T. Holl, G. H¨ ogstr¨ om, and W. L¨ owe. Automatic design pattern detection. In 11th Int. Workshop on Program Comprehension (IWPC 2003), May 10-11, 2003, Portland, Oregon, USA, pages 94–103, 2003. M. Koshkina and F. van Breugel. Modelling and verifying web service orchestration by means of the concurrency workbench. SIGSOFT Softw. Eng. Notes, 29(5):1–10, 2004. C. Kr¨ amer and L. Prechelt. Design recovery by automated search for structural design patterns in object-oriented software. In Proceedings of IEEE Working Conference on Reverse Engineering, pages 208–215, 1996. N. Milanovic. Service engineering design patterns. In SOSE ’06: Proc. of the 2nd IEEE Int. Symposium on Service-Oriented System Engineering (SOSE’06), pages 19–26, Washington, DC, USA, 2006. R. Milner. Communication and concurrency. Prentice-Hall, Upper Saddle River, NJ, USA, 1989. H. Motahari Nezhad, R. Saint-Paul, B. Benatallah, and F. Casati. Protocol Discovery from Imperfect Service Interaction Logs. In Proceedings of the 23nd International Conference on Data Engineering (ICDE), pages 1405–1409, April 15-20 2007. J. Smith and D. Stotts. SPQR: Flexible automated design pattern extraction from source code. In Proc. of the 18th IEEE Intl Conf on Automated Software Engineering, Montreal QC, Canada, 2003. C. Stirling. An Introduction to Modal and Temporal Logics for CCS. In Concurrency: Theory, Language, And Architecture, pages 2–20, 1989. N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, and S. T. Halkidis. Design Pattern Detection Using Similarity Scoring. IEEE Transactions on Software Engineering, 32(11):896–909, 2006. J. Yang and D. Evans. Automatically Inferring Temporal Properties for Program Evolution. In Proc. of the 15th Int. Symposium on Software Reliability Engineering (ISSRE’04), pages 340–351, Washington, DC, USA, 2004. IEEE.
