ArticlePDF Available

Implementing Minimally Adequate Synthesizer

Authors:

Abstract

Minimally Adequate Synthesizer (MAS) is an algorithm that synthesizes UML statechart diagrams from sequence diagrams. It follows Angluin's framework of minimally adequate teacher to infer the desired statechart diagram with the help of membership and equivalence queries. The purpose of this paper is to discuss problems related to an practical implementation of MAS. In order to be able to handle most membership queries without consulting the user, MAS maintains a structure of strings already known to belong to the unknown language. User's erroneous answers and mind changes require an implementation of the structure that is capable of handling backtracking. We sketch a trie based implementation to allow this. Moreover, we discuss the interaction between the user and the algorithm as a medium of improving the algorithm and further decreasing the number of membership queries needed. Furthermore, we show how MAS can be used to synthesize sequence diagrams into an edited or manually cons...
A
U
N
V
E
R
I
T
S
I
S
P
R
E
E
S
M
I
A
T
S
N
a
b
c
d
g
i
VOID
e
f
h
VOID
VOID
3
1
2
(x1,y1), (x2,y2)
(x3,y3)
(x4,y4)
q
0
q
+
(s_ct,set)
(s_ct,VOID)
(s_ct,VOID)
(buzz,off)
(s_ct,reached)
(s_at,NULL)
(s_ct,set)
... The over-generalization issue is not tackled in the context of this study. However, there are synthesizers which can avoid over-generalization, e.g., through interactive synthesis as implemented in MAS (Minimally Adequate Synthesizer) [39,40]. ...
... MAS (Minimally Adequate Synthesizer) [39,40] is a command line tool developed for synthesizing application traces. MAS infers a state machine diagram from simple message sequences following Angluin's framework of a minimally adequate teacher [3]. ...
... The well-known problem of over-generalization can be handled in various ways. In [39,40], MAS handles this prior to or during the synthesis when run in an interactive mode. The over-generalization problem has been acknowledged (e.g. by Uchitel et al. [67]). ...
Thesis
Full-text available
Service-oriented architecture (SOA) is a software architectural style, which relies on reusable and composable services. In addition to software-orientation, SOA includes a business viewpoint, so that business requirements can be captured as high level business processes. Business processes can be implemented, for example, as an orchestration of different service components. Individual services participate in the overall execution of business processes by providing elementary service activities. In addition to flexibility and services reuse, bridging of business and information technology (IT) views is one of the claimed benefits of SOA. Development of service-based systems includes a range of different activities. However, development of service-based systems is still lacking systematic and tool vendor independent practices and development methods. In this thesis, a development process for a service provider, called Service Product Development Process (SPDP), is presented. It consists of several development phases and related activities. The input for SPDP includes high level business process requirements. The result of the process is a new service-based product to be added to the service provider’s product portfolio. The purpose of this thesis is to study the applicability and the benefits of applying a scenario-driven approach, a type of requirement-driven development, for the development of service-based systems. Scenarios are used to capture functional system requirements as simple message sequences given as UML sequence diagrams. The scenario-driven approach is applied to different phases of SPDP including business process development, service specification, and service realization. The proposed scenario-driven approach is not limited to the SPDP context. It is rather a general purpose framework for development of service-based systems or products, called SceDA. SceDA includes three independent scenario-based methods, which are targeted to support different development phases of service-based systems. One of the three methods is used for scenario-based business process development. The other two methods are targeted at service development, in particular, service specification and service realization. Service specification is supported by a method for automatically mining and re-documenting the development rules as scenarios. To support service realization, a method for generating source code for individual service and client applications has been developed. Each method includes a description of the developed tool support and a case study. Case studies are used for constructing and evaluating the three scenario-based methods developed. Each method is applied as a case study in the context of development phases of SPDP. In the first case study, scenario-driven business process development method is applied. Two other case studies concern constructing and using scenarios for application development. One case study utilizes the scenario mining method. In the other case study, the code generation method is applied.
... Due to our knowledge, Sced [Sced,MS00,MS01,Sys97,KMST94] is the only tool that provides such a functionality. Sced provides sequence diagrams and statecharts. ...
... So far, we mainly provide consistency checks. Current work incorporates the concepts of [MS00,MS01] into SDM and Fujaba. The idea is to analyse scenarios with respect to traces of signals and actions received and executed by certain kinds of objects. ...
... These were then analyzed according to the criteria detailed in section 2.4 and data was recorded in an Excel file. Two papers [23,24] found by the CiteSeer search engine were not included in the primary studies because they led to a subsequent, more complete publication [10] by the same authors. We only show results for five out of the seven search engines because Google Scholar did not return any results and Engineering Village and Inspec used the same search engine interface and database. ...
Technical Report
Full-text available
Context: The Unified Modeling Language (UML), with its 14 different diagram types, is the de-facto standard modeling language for object-oriented modeling and documentation. Since the various UML diagrams describe different aspects of one, and only one, software under development, they are not independent but strongly depend on each other in many ways. In other words, diagrams must remain consistent. Dependencies between diagrams can become so intricate that it is sometimes even possible to synthesize one diagram on the basis of others. Support for synthesizing one UML diagram from other diagrams can provide the designer with significant help, thus speeding up the design process, decreasing the risk of errors, and guaranteeing consistency among the diagrams. Objective: The aim of this article is to provide a comprehensive summary of UML synthesis techniques as they have been described in literature to date in order to obtain an extensive and detailed overview of the current research in this area. Method: We have performed a Systematic Mapping Study by following well-known guidelines. We selected ten primary studies by means of a search with seven search engines performed on October 2, 2013. Results: Various results are worth mentioning. First it appears that researchers have not frequently published papers concerning UML synthesis techniques since 2004 (with the exception of two papers published in 2010). Only half of the UML diagram types are involved in the synthesis techniques we discovered. The UML diagram type most frequently used as the source for synthesizing another diagram is the sequence diagram (66.7%), and the most synthesized diagrams are the state machine diagram (58.3%) and the class diagram (25%). Conclusion: The fact that we did not obtain a large number of primary studies over a 14 year period (only ten papers) indicates that synthesizing a UML diagram from other UML diagrams is not a particularly active line of research. Research on UML diagram synthesis is nevertheless relevant since synthesis techniques rely on or enforce diagram consistency, and studying UML diagram consistency is an active line of research. Another result is that research is needed to investigate synthesis techniques for other types of UML diagrams than those involved in our primary studies.
Article
Full-text available
The development of services-based systems starts from defining business requirements to be implemented as high-level business processes. In this paper, we describe a scenario-driven approach for developing business processes specified as WS-BPEL descriptions. We aim for simplicity in the business level notation and leverage example-like modelling principles in order to enable process sketching. The first step in our approach is to identify the essential functional requirements for business processes. The requirements are modelled as simple scenarios, each of them defining a sample run through the process, i.e., required behaviour that the underlying service-based system should allow. The scenarios, specifying sent and received messages among the services, are synthesised into a state machine. The state machine is transformed into an initial process model given in UML activity model notation. To enable mapping into WS-BPEL code, the transformation exploit domain-specific rules, i.e., our target model consists of a subset of UML with WS-BPEL specific constraints and stereotypes. The initial process model can be further refined to enable generation of executable WS-BPEL descriptions. We apply the approach on two cases, a simple process for managing loan requests and an industry case study from a logistics provider are presented.
Conference Paper
The development of services-based systems starts from defining goals for business processes to be implemented, e.g., as a Web service orchestrations specified in WS-BPEL. In this paper, we propose a scenario-driven approach for modeling business processes. We aim for simplicity in the notation and leverage example-like modeling principles in order to improve process sketching. The first step in our approach is to identify the essential business requirements and model them using a simple scenario notation. The scenarios, given as UML sequence diagrams, are synthesized into a state machine, which is translated into a WS-BPEL flavored process skeleton given as UML activity diagram. The process skeleton can be further refined into executable process model.
Article
. We consider the problem of synthesizing UML statechart diagrams from sequence diagrams as a language inference problem, and we solve it in Angluin's framework of minimally adequate teacher. The designer has the role of the teacher who answers membership and equivalence queries made by the algorithm. It turns out that there are several natural methods to decrease the number of membership queries needed, and thus, to make the algorithm practically applicable.
ResearchGate has not been able to resolve any references for this publication.