Behavior_Model_Discovery_to_Support_Reverse_Engineering_of_Object-Oriented_Software

硕士学位论文 Dissertation for Master’s Degree (工程硕士) (Master of Engineering) Behavior Model Discovery to Support Reverse Engineering of Object-Oriented Software 支持面向对象软件逆向工程的行为模型挖掘 杜伟 2012年9月 国内图书分类号：TP311 学校代码：10213 国际图书分类号：681 密级：公开 工程硕士学位论文 Dissertation for the Master’s Degree in Engineering (工程硕士) (Master of Engineering) Behavior Model Discovery to Support Reverse Engineering of Object-Oriented Software 支持面向对象软件逆向工程的行为模型挖掘 |硕士研究生 |： |杜伟 | |导 师 |： |聂兰顺, 副教授 | |副导师 |： |Zacharewicz Gregory，副教授 | |申请学位 |： |工程硕士 | |学科 |： |软件工程 | |所 在 单 位 |： |软件学院 | |答 辩 日 期 |： |2012年9月 | |授予学位单位 |： |哈尔滨工业大学 | Classified Index: TP311 U.D.C: 681 Dissertation for the Master’s Degree in Engineering Behavior Model Discovery to Support Reverse Engineering of Object-Oriented Software 支持面向对象软件逆向工程的行为模型挖掘 |Candidate： |DU Wei | |Supervisor： |NIE Lanshun，Associate professor | |Associate Supervisor: |Zacharewicz Gregory，Aso.Prof. | |Academic Degree Applied for： |Master of Engineering | |Speciality： |Software Engineering | |Affiliation： |School of Software | |Date of Defence： |September, 2012 | |Degree-Conferring-Institution： |Harbin Institute of Technology | 摘 要 如今，在经济全球化的背景下，企业的合作变得越来越重要。企业往往需要在同一时间与许多具有有不同的技术，语义，工作方法和组织的合作伙伴进行互操作。在这种情况下，它需要一个合适的解决方案，以避免这些差异造成的合作障碍。 我的项目是基于PHDTUzhiying的研究[2]，他的项目研究思想是提出开发一个叫federated approach的方法用以提高企业互操作性的方法。在这项研究将提出一个解决方案，以实现federated approach，并展示了一些具体的例子提出的解决方案的可行性。这种动态的方法被称为federated，其目的是建立动态的互操作性。我的项目是其方法结构的一部分，主要工作是从原有系统中逆向提取动态模型以用来抽象表示企业系统的业务流程和行为模型。 本论文的阐述了动态和静态信息的集成可以提高逆向工程任务的性能。实验环境用来支持Java软件系统的逆向工程被实现。从Java源代码可以提取静态的模型。它可以被与逆向工程的工具用来查看和分析。为了分析原有的系统我们采用程序分析器来剖析程序的信息以生成静态模型，动态事件跟踪的信息Jprofile是自动生成一个定制的Java开发工具包（JDK）调试器下运行的目标系统分析器。也可以提取关于选定的对象或方法的动态控制流的信息。Event trace可以结合静态模型比如时序图被查看和分析来描述系统的状态流分析。然后根据生成状态图的算法自动生成状态图建模逆向工程的应用程序的运行行为的结果。然而这个生成的状态图是有限状态机（FSM），由于状态图可以克服的有限状态机的限制，我们提出了一个方法从有限状态机中提取状态图，将有限状态机（FSM）转化成相应的状态图。 关键词：逆向工程，状态图，静态模型，动态模型，模型提取 Abstract Nowadays, enterprise collaboration becomes more and more important because of globalized economic context. An enterprise often needs to interoperate at the same time with many different heterogeneous partners having different technologies, semantics, methods of work and organizations. In this context, it needs a proper solution to avoid the collaboration barriers caused by those differences. The objective of the paper is to propose developing a federated approach for enterprise interoperability. In this research will present a solution to achieve federated approach and demonstrate the feasibility of the proposed solutions with some concrete examples. This dynamic approach called federated which aims to establish interoperability on the fly. Based on the PHD Tu zhiying’s research [2], my subject is a part of his research and based on his structure. This dissertation shows that integration of dynamic and static information aids the performance of reverse engineering tasks. An experimental environment has been built to support reverse engineering of Java software systems. And the static information of the system could be generated from the source code. The reverse engineering tool could view and analysis the static information. Then the dynamic event trace is generated automatically by the program tracer Jprofiler to be the result of running the target system under a customized Java Development Kit (JDK) debugger. Information about the dynamic control flow of selected objects or methods can also be extracted. The event trace can then be viewed and analyzed with the already existed static model like sequence diagram to describe the state flow of the system. Then according to the state diagram algorithms automatically generate the statechart to model the results of reverse engineering the run-time behavior of the applications. This generated statechart is Finite State Machines (FSM), since statechart can overcome the limitation of the Finite State Machine; we propose a method to expect statechart from FSM, finally we add the time element to each transmission from the state, in that case we could generate a simple DEVS model. Keywords: Reverse Engineering; Statechart; Static model; Dynamic model; Model behavior 目 录 摘 要 I Abstract II Chapter 1 Introduction 1 1.1 Backgroud 1 1.2 The purpose of project 4 1.3 The status of related research 5 1.3.1 Enterprise interoperability 5 1.3.2 Software Reverse Engineering 6 1.3.3 Harmonized federate structure 9 1.3.4 Scenario Diagram and State machine 10 1.4 Main content and organization of the thesis 12 1.4.1 Main content of my project 12 1.4.2 Organization of the thesis 13 Chapter 2 System Requirement Analysis 14 2.1 The goal of the system 14 2.2 The requirements analysis 15 2.2.1 Enterprise interoperability requirement analysis 15 2.2.2 Harmonized federate structure requirement analysis 17 2.2.3 Process of abstracting the dynamic model requirement analysis 18 2.2.4 Use case of the system 20 2.3 Brief summary 21 Chapter 3 System Design and Implementation 22 3.1 Overview of the System Design 22 3.1.1 Development process of the system 22 3.1.2 System structure design 24 3.2 The execution of the event tracer Jprofiler 25 3.2.1 Tracing the legacy system by program tracer Jprofiler 25 3.3 Editoring the event trace to scenario diagram 31 3.3.1 Generation of scenarios overview 31 3.3.2Compaction of Repetitions 33 3.3.3 Compaction of Recursive Calls 35 3.3.4 Drawing Sequence Diagram 35 3.3.5 Evaluation 38 3.4 Algorithm Design for synthesizing state machine 44 3.4.1 The BK-algorithm 44 3.4.2 Adapted algorithm for synthesizing state machine 48 3.4.3 Conclusion of the Adapted BK-algorithm 52 3.5 Implementation of synthesizing state machine 53 3.5.1 Synthesis of state machine from scenarios 53 3.5.2 Approach of synthesis 57 3.5.3 Establishment of initial state machines 57 3.5.4 Synthesis of final state machines 60 3.6 Generation of statechart from representation of FSM 65 3.6.1 Example of FSM 67 3.6.2 Statechart analysis 69 3.6.3 Decomposition of the FSM 71 3.6.4 A Statechart Extraction Methodology 73 3.6.5 The implementation of the Theorem Method 75 3.6.6 Conclusion of this section 78 3.7 Key techniques 79 3.8 Brief summary 79 Chapter 4 Implementation of prototype tool and Testing 80 4.1 The environment of prototype implementation 80 4.2 Implementation of the synthesis of state machine prototype 80 4.2.1 Implementation of input scenarios 80 4.2.2 Implementation of Generating State Machine 84 4.2.3 Implementation of statechart of the experimental system 87 4.3 The prototype tool Testing 89 4.3.1 Testing plan 89 4.3.2 Test Cases and results 90 Conclusion 95 References 97 Acknowledgement 103 Chapter 1 Introduction 1.1 Backgroud Firstly, nowadays, enterprise collaboration becomes more and more important because of globalized economic context. An enterprise often needs to interoperate at the same time with many different heterogeneous partners having different technologies, semantics, methods of work and organizations. In this context, it needs a proper solution to avoid the collaboration barriers caused by those differences. So the Enterprise Interoperability is required to be a sustainable interoperability with low cost, excellent discovery ability, learning ability, adaptability, and reusability. In order to achieve the common goal and realize the enterprise interoperability, the enterprises need to cooperate seamlessly, in an automated manner, in depth of time. Thus, this means that they need a very efficient, dynamic, sustainable and seamless approach/solution, so they need the Enterprise Interoperability Dynamics. There is an approach called the federated approach [1] to achieve enterprise interoperability dynamic which focuses on the data and service concerns of the interoperability conceptual, and my research is under the structure of the federated approach.Figure1-1 see in [1], [2] illustrates the scheme of the federate approach, enterprise uses model reverse engineering to discover the models from the legacy system based on enterprises’ requirement and our interest. And then, rewind these models into MDA models based on the alignment of MDA and HLA FEDEP, and solve interoperability problem of each level of MDA models according to the principle of MDI framework. And our research may mainly concentrate on the Data transmission level between the federate interfaces for the different enterprise. Then generate a Federate Interface, which can plug into the HLA platform and transmit the information with other companies’ information systems via RTI. In that case the different enterprises could construct integration on the platform without considering the transmission and processing of the data and information. [1] [pic] Figure1-1: Enterprise interoperability through Federate Interface Developments of information and communication technologies (ICTs) [3] and turbulent market conditions have forced small and medium size enterprises (SMEs) to adapt their way of undertaking business, from traditional practices to e-business. In this context, new forms of collaboration have emerged, such as Collaborative Networks (CNs) or virtual enterprises (VEs). [3] In a collaborative networked environment (CNE), the integration and interoperability enhance the competitive advantages of the CNs and their member organizations. In this context, they become critical goals towards achieving their business objectives in a time, quality and cost effective manner. Secondly, the need for maintaining, reusing, and re-engineering existing software systems has increased dramatically over the past few years. Changed requirements or the need for software migration, for example, necessitate renovations for business-critical software systems. Reusing and modifying legacy systems are complex and expensive tasks because of the time-consuming process of program comprehension. Thus, the necessary for software engineering methodology and tools that promote program understanding is very necessary. A variety of reverse engineering tools provide means to support this task. Reverse engineering aims at analyzing the software and representing it in an abstract form so that it is easier to understand, e.g., for software maintenance, reengineering, reuse, and documenting purposes. The static and dynamic information are very useful for realizing the target system. Static information illustrates the structure of the software, while dynamic information demonstrates the run-time behavior of the system. Both static and dynamic analyses result in information about the software products and their relations. The dynamic analysis also produces sequential event trace information, about concurrent behavior, code coverage, memory management, etc. Program understanding usually could be sustained by producing design models from the legacy target software. So, this reverse engineering approach is also useful when constructing software from high-level design information, i.e., during forward engineering. The extracted static models can be used, for instance, to ensure that the architectural guidelines are followed and to get an overall picture of the current stage of the software. The dynamic models, in turn, can be used to support tasks such as debugging, finding dead code, and understanding the current behavior of the software. Thirdly, a very common problem of the reverse engineering is that understanding legacy systems and derive abstract characterizations of poorly documented software. In the case of object-oriented software, the static structure (e.g. inheritance and association relationships) can usually be understood easily, and it can be extracted from existing software using automated tools. This is due to the fact that the static aspects of object-oriented programs are well known and more or less explicitly indicated in the source. Understanding and characterizing the dynamic behavior of such systems, in contrast, is usually much more difficult because of the gap between the static source text and the run-time behavior of the resulting executable program. However, the dynamic behavior of a program is equally important as its static specification for understanding the software. Dynamic characterization is particularly important for those parts of a system which are mainly understood by their dynamic behavior, like various kinds of controllers, drivers etc. For instance, assume that the control unit of an elevator needs to be re-engineered, and that this software lacks all documentation. We can identify certain classes in the source that presumably represent various kinds of controller objects, but on the basis of the source we can only observe that they react on certain kinds of events in a particular way, dependening on their current state, and that they in turn send certain events to other objects. However, it is extremely difficult to infer the general behavior of such objects in the form of, say, and state diagram on the basis of static information only. The situation is somewhat better if the source is systematically written to reflect the structure of a state machine, but this is often not the case. 1.2 The purpose of project The Enterprise Interoperability is required to be a sustainable interoperability with low cost, excellent discovery ability, learning ability, adaptability, and reusability. In order to achieve the common goal and realize the enterprise interoperability, the enterprises need to cooperate seamlessly, in an automated manner, in depth of time. Thus, this means that they need a very efficient, dynamic, sustainable and seamless approach/solution, so they need the Enterprise Interoperability Dynamics. The objective of the paper is to propose developing a federated approach for enterprise interoperability. In this research will present a solution to achieve federated approach and demonstrate the feasibility of the proposed solutions with some concrete examples. This dynamic approach called federated which aims to establish interoperability on the fly. Based on the PHD Tu zhiying’s research [2], my subject is a part of his research and based on his structure, a novel Federated interoperability platform is proposed. It reuses distributed simulation interoperability concepts to facilitate and coordinate the communication between heterogeneous distributed information systems of the enterprises. The platform is complaint with the latest version of the High Level Architecture (HLA) that is a distributed communication standard. This framework is also proposing a development lifecycle that is tending to reuse existing information systems without recoding them but by adapting them to the new requirements of interoperability dynamics. Since scenario models and state machine models play central roles in current object-oriented system modelling processes. They provide two different views of systems.The former view describes system behavior as sequences of responsibilities that need to be executed by components in order to achieve overall system requirements, while the latter view addresses complete component behavior in terms of states and transitions. The dynamic model analysis also produces continuous event trace information, information about concurrent behavior, code coverage, memory management, Program understanding thus could be sustained by generating design models from the target software. This dynamic reverse engineering approach is also useful when constructing software from high-level design information; it can be used to support tasks such as debugging, finding dead code, and understanding the current behavior of the software. So extracting information about the dynamic behavior of the software is especially important when examining object-oriented software. Overall, the ultimate goal of the research subject is to improve the level of Enterprise interoperability with reliable platform which the different enterprises can apply. In that case to meet the requirements of fully computerized and automated integration. 1.3 The status of related research 1.3.1 Enterprise interoperability • Enterprise interoperability background Enterprise interoperability qualifies the faculty of enterprise to establish a partnership activity (in product design, organization of the activities of production, supply chains piloting) in an efficient and competitive way in an environment of unstable market. Also, inside a company, the need in interoperability of the various services is very generally identified [4, 5]. In the current industrial and economic context, enterprise systems need to be constantly and smoothly re-engineered to respond to changing market demand and technological evolution. Enterprise architecture, considered as the foundation of enterprise systems engineering, has emerged as a tool to help stakeholders to manage system engineering and changes. It is not only an IT issue, but first of all a strategic and organizational challenge. • Enterprise Interoperability Framework The Enterprise Interoperability Framework was initially proposed within the INTEROP NoE and now in the process of standardization as CEN/ISO 11354-1 (Chen et al., 2007). The Framework defines three basic dimensions for Enterprise Interoperability as follows (see Figure1-2): [2] [pic] Figure1-2: Enterprise Interoperability Framework ➢ “Interoperability concerns” which identifies the area of interoperation that may take place at various levels of the enterprise (data, service, process, business), i.e. the level at which the interoperation occurs. ➢ “Interoperability barriers” which identifies various obstacles to interoperability in three categories (conceptual, technological, and organizational), i.e. the type of obstacle to interoperability. ➢ “Interoperability approaches” which represents the different ways in which barriers can be removed (integrated, unified, and federated). 1.3.2 Software Reverse Engineering Reverse engineering is the process of analyzing the subject system to the produce representations of the system at a higher level abstraction. Trying to figure out the structure [4] and behavior of existing software by building general-level static and dynamic models. Figure1-3 demonstrates the Process between forward and reverse through the software engineering lifestyle. [pic] Figure1-3: Process between forward and reverse engineering We can see from the model, the process of the implementation phase is reverse-engineered back to the analysis phase, in a reverse of the a waterfall model. Reverse engineering is a process of inspection. [4] • Model-Driven Architecture (MDA) It provides a set of instructions for the structuring of specifications; the specifications are expressed as models. MDA is a kind of domain engineering, and supports model-driven engineering of software systems. It was preceded by the Object Management Group (OMG) in 2001. Figure1-4 [5] lays out the Model Driven. UML is the key technology for the Model Driven Architecture: Every application using the MDA is based on the standard and platform-independent UML model. By using this accepted modeling standard, the MDA allows the establishment of applications that are portable across, and interoperate naturally across. The core of the architecture, at the center of the figure, is based on OMG’s modeling standards: UML, the MOF and CWM. There will be multiple core models1: One will represent Enterprise Computing with its component structure and transactional interaction; another will represent Real-Time computing with its special needs for resource control; more will be added to represent other specialized environments but the total number will be small. Each core model will be independent of any middleware platform. The number of core models stays small because each core model represents the common features of all of the platforms in its category. The first step when constructing an MDA-based [8] application will be to create a platform independent application model by UML in terms of the core model, no matter the ultimate target is CCM, EJB, or other component or the platform, Platform will convert this general application model into one targeted to a specific platform like CCM, EJB, or MTS. Standard mappings will lead tools to automate the transformation. In Figure 1-4, [3] we can see these target platforms occupy the ring surrounding the core. [pic] Figure1-4: OMG’s Model Driven Architecture • Architecture-driven modernization Architecture-driven modernization is the name of the initiative of the Object Management Group related to building and promoting standards that can be applied to modernize legacy systems. The objective of this initiative is to provide standard representations of views existing systems in order to enable common modernization activities like code analysis and comprehension, and software transformation [6]. The Object Management Group (OMG) Architecture-Driven Modernization (ADM) task force is currently engaged in a series of standards development activities. The mission of this task force is to further the ability of organizations to successfully modernize existing information systems. Existing systems modernization is the process of understanding and evolving existing software assets to further one or more business or organizational objectives. 1.3.3 Harmonized federate structure Based on the PHD Tu zhiying’s research [1], [2], a novel Federated interoperability platform is proposed. It reuses distributed simulation interoperability concepts to facilitate and coordinate the communication between heterogeneous distributed information systems of the enterprises. The platform is complaint with the latest version of the High Level Architecture (HLA) that is a distributed communication standard. This framework is also proposing a development lifecycle that is tending to reuse existing information systems without recoding them but by adapting them to the new requirements of interoperability dynamics. A structure called Harmonized federate structure can be seen in Figure1-5 see in [1]. We can consider a federate as a converter. A federate has two parts, one is Adapter and another is Plug-in. Adapter has Enterprise Business Behavior Interface, which associated with the enterprise business process related to specific strategies and algorithms of different enterprises. Plug-in has Integration code, which manages the interactions between the enterprise business behaviour interface and the RTI, providing an RTI independent API to the enterprise business behaviour interface, and a simulation independent API to the RTI services. The objective of these abstractions is to ensure that the enterprise business behaviour remains decoupled from RTI services. After the harmonization, all federates will have the same Integration code but different Enterprise Business Behaviour Interfaces. Meanwhile, any simulation related services required by the enterprise business behaviour interface are accessed via the integration code, rather than through direct interaction with the RTI. As a result, integration code is common components for all federates of the existing coordinators and also the reusable components for the future coordinators. In addition, enterprise business behaviour interface will adapt to different legacy systems of different enterprises. It will be implemented based on specific strategies and algorithms of different enterprises and it will accomplish the cipher mission. As related to my work, because my project is based on this already proposed structure, the main content of my topic focus on the Adapter, we try to implement an interface to abstract the business behavior from the static information extracted from legacy system. And enterprise business behavior interface will adapt to different legacy systems of different enterprises. It will be implemented based on specific strategies and algorithms of different enterprises. [pic] Figure1-5: Harmonized federate structure 1.3.4 Scenario Diagram and State machine • Scenarios A scenario is a sequence of events that occurs during an execution of a system. A scenario is presented informally as a sequence of statements in natural language. For a traffic light system two scenarios could be given as follows [10, 11]: Scenario diagrams are a well-known graphical notation for illustrating a sequence of communication events occurring during a particular run of an object-oriented system. Traditionally scenario diagrams are used in the analysis and design phases of software development to visualize the expected dynamic behavior of a system. We show how scenario diagrams can be used reversely as the basis of understanding existing systems. A prototype tool has been implemented with the ability to automatically produce scenario diagrams for existing systems and to scan these diagrams in various ways. The tool [10], has additional properties typical for high-level debuggers, program profilers, and program animators. In Figure 1-6 [4], Scenario diagrams are shown for the example scenarios. [pic] Figure1-6: Event Scenario diagrams related to the sample scenarios • State machine A state is an abstraction of values of an object. Then in a system, objects interact with each other, causing changes to their states. A stimulus from one object to another is an event. The event could change the state. The change is called a transition. A system includes states, events and transitions which can be represented as a state machine (or state diagram). A state machine is a directed graph in which states are represented by nodes and transitions are represented by directed edges [12]. A state can be associated with an action. An action is either a continuous activity ending when leaving the state (e.g. displaying a moving picture on the screen), or a finite sequence of operations ending when the operations are completed (e.g. Opening a valve); in both cases the action starts immediately after entering the state. Also, in both cases the action is interrupted if an external event causing a state transition is received. If a transition has no event (so-called default transition)[9],[12], it fires immediately when the action in the state is completed. A state machine may have a special initial state and final states. A state machine describes the behavior of a single class of objects. The state machines for various classes combine into a single dynamic model via shared events. In Figure 1-6, a state machine is presented for the control unit of the traffic light system. Note the use of guards: it is assumed that the information provided by the traffic sensors can be used in selecting the next transition, in addition to events. There is an intimate relation between the trace diagram given previously and the state machine in Figure 1-7. Following the vertical line of the control unit object from top to bottom, the events in the trace diagram can be found on a path in the state machine. Each leaving event appears as an action and each arriving event appears as a transition event [13]. [pic] Figure1-7: A state machine for the control unit of a traffic light system 1.4 Main content and organization of the thesis 1.4.1 Main content of my project This section mainly demonstrates the main content and the main framework of my project, as well as the organization of the thesis. Based on the PHD Tu zhiying’s research [1], [2], a novel Federated interoperability platform is proposed. And also a structure called Harmonized federate structure can be seen in Figure1-5 see in [1]. My work mostly focus on the Adapter that according to static model extract dynamic information to abstract the business behavior flow of the system, and enterprise business behavior interface will adapt to different legacy systems of different enterprises. It will be implemented based on specific strategies and algorithms of different enterprises. Futhermore, this subject proposes an approach to reverse-engineer statecharts automatically from a program traces.The purpose of reverse-engineering dynamic models is to accomplish high-level analyses, especially for conformance checking and pattern identification. As demonstrated above my work supposes to go beyond static models by coming up with an approach for the reverse-engineering UML sequence diagrams and statecharts and also for using this reverse-engineered dynamic models to promote high-level analyses. So generally the key work of this topic is to use program tracer to get the event trace of the system, and then combine with the already existed static model to draw the scenario, and then put forward a reverse approach for state machine from scenario models based on the basic concept of BK-algorithm [18, 19]. And then we introduce hierarchy to the generated flat state machine in terms of the UML composite state. After that we transfer the Finite State Machine to the statechart according to the adapted method in order to gain the equivalent statechart from FSM. Then through the method we already proposed and add the timing issue to the statechart, we could probably generate a simple DEVS model to represent the system’s business process. 1.4.2 Organization of the thesis This thesis will include 4 main chapter, chapter 1 introduce the background and related research of the project, chapter 2 will introduce the requirement analysis of the project, chapter 3 mainly discuss the system design of the whole project including each methodology and algorithm we construct and proposed during each phase, Chapter 4 will demonstrate the implementation of the prototype tool to apply the experimental system through the methodology and algorithm. Finally we have a conclusion part in the end. Chapter 2 System Requirement Analysis 2.1 The goal of the system During this internship research the expected goal of my system and project is as follows: Automatically or mostly automatically generate dynamic behavior diagram on the condition that already existing the UML diagrams and models. We can extract the useful information from the enterprise software system, and then apply the statistic we get to abstract a business process behavior, the behavior will be visualized in statechart or DEVS model, so that we can abstract and construct business interaction between different enterprises. The system can present the business process of the enterprise according to the static model. In the end it may probably combined with the PHD Tu zhiying’s project [1] [2] construct an Enterprise Business Behavior Interface as the adapter Harmonized federate structure in order to ensure a sustainable interoperability between enterprises. [pic] Figure2-1: Key process and framework of the project Figure2-1 shows the key process and expected objective of each process, it’s a framework of our project system, first extract static model form code and legacy system presented in UML diagram like class diagram, sequence and collaboration diagram, based on the static model we apply corresponding method and adapted algorithm to extract behaviour model from the static model to represent the business process of the system, after the generation of the behaviour model represented in statechart and scenario diagram. According to the statechart we analysis the dynamic model to conduct it generate the advanced process model like DEVS, petri NET, IDEF. And then we can combine the static model and dynamic model in the adapter enterprise business behaviour interface to process the system business behaviour. In general, the ultimate goal of my research subject is to make contribution to the proposed federated approach for enterprise interoperability that aiming at improves the level of Enterprise interoperability with reliable platform which the different enterprises can apply. In that case to meet the requirements of fully computerized and automated integration. And also the project will support the analyzing the software and representing it in an abstract form so that it is easier to understand, as well as for software maintenance, re-engineering, reuse, and documenting purposes. 2.2 The requirements analysis 2.2.1 Enterprise interoperability requirement analysis Nowadays, in the globalised economic situation, the competitiveness of an enterprise depends not only on its internal productivity and performance, but also on its ability to collaborate with other enterprises. This necessity leads to the development of a new concept called Enterprise interoperability that allows enhancing collaborations between enterprises. Consequently, more and more networked enterprises are developed. And enterprise interoperability is considered as one of the most compatible solution to the enterprise integration. As can be seen in Figure 2-2, it is a schema of the related scenario proposed by the PHD Tu zhiying; it is assume that before enterprises start to launch a cooperative project, they all have their own systems. Thus, the goal is to achieve the interoperability among those legacy systems. [pic] Figure 2-2: enterprise interoperability scenario description In the schema shown in Figure2-2, we can apparently see that enterprise A, B, C construct cooperation through the interconnection network. So there are three steps to implement the cooperation among these different enterprises. ➢ Model reverse engineering will be used to discover the models from the legacy system based on enterprises’ requirement and our interest. Then, it will rewind these models into MDA models. Meanwhile, it will solve interoperability problem of each level of MDA models according to the principle of MDI framework. ➢ It will test the final models come from model reverse engineering. After that, it will transform correct models to code, and generate the Federate Interface, which can plug into the platform and transmit the information with other companies’ information systems. ➢ If there are other enterprises want to join this cooperative project, they also need to follow the step 1 and step 2, to reverse engineer their legacy system into MDA models, and remove the incompatible parts, then generate the Federate Interface, finally, synchronize with other systems. Therefore, according to the setp 1 and setp 2, a model reverse engineering should be carried out to abstract the legacy system in order to generate the common behavior model represent the business process of the enterprise. So both static and dynamic model of the enterprise system should be presented to indicate the legacy system, meanwhile an experimental environment need to been built to support this reverse engineering. Through the experimental example we can approximately imitate the abstraction of the enterprise’s system. 2.2.2 Harmonized federate structure requirement analysis As the projecet is based on PHD Tu zhiying’s research, which has already proposed a structure called Harmonized federate structure to cooperative the business of different enterprise, my project should be carried out under the framework of this structure. As the figure 2-3 [1] indicates, eache enterprise which need to cooperative with others need to connect the HLA platform, and each enterprise already has their own legacy system, therefore a common abstraction of the behavior model is necessary to implement. It is shown in the schema as Enterprise Business Behavior Interface or can be known as an adapter, in order to get the behavior of legacy system of the enterprise, a dynamic reverse abstraction is necessary to construct. As a result, an approach should be proposedto visualize the run-time behavior of the target enterprise system. [1, 2] In the other hand, for the integration code or been called Plug-in, any simulation related services required by the enterprise business behaviour interface are accessed via the integration code, rather than through direct interaction with the RTI. As a result, integration code is common components for all federates of the existing coordinators and also the reusable components for the future coordinators. In addition, enterprise business behaviour interface will adapt to different legacy systems of different enterprises. It will be implemented based on specific strategies and algorithms of different enterprises and it will accomplish the cipher mission. [pic] Figure2-3: Existed Harmonized federate structure As a conclusion, the whole overall project has already gained these achievements: • Fully defined the framework of the whole methodology. • An implementation of HLA Evolved Web Services has been carried out with an open source RTI • The laboratory case study has proved the feasibility and efficiency of HLA Evolved WS methodology Consequently, the further work should be focused on: • Implementation of model reverse engineering • Apply the reverse approach in the experimental environment • Automatically generate the behavior of the target enterprise system • A coming industrial case will allow to test the proposed approach in an industrial context and improve its performance. 2.2.3 Process of abstracting the dynamic model requirement analysis A basic problem of reverse engineering is to understand legacy systems and derive abstract characterizations of poorly documented software. In the case of object-oriented software, the static structure can usually be understood easily, and it can be extracted from existing software using automated tools. This is due to the fact that the static aspects of object-oriented programs are well known and more or less explicitly indicated in the source. Understanding and characterizing the dynamic behavior of such systems, in contrast, is usually much more difficult because of the gap between the static source text and the run-time behavior of the resulting executable program. However, the dynamic behavior of a program is equally important as its static specification for understanding the software. Dynamic characterization is particularly important for those parts of a system which are mainly understood by their dynamic behavior, like various kinds of controllers, drivers and also like our target project’s system which need the Enterprise Business behavior interface to construct the corresponding among different enterprises. [10] The process of abstracting the dynamic model is as follows, the visualization of dynamic model is scenarios (sequence diagrams), State diagrams and (hierarchical) graphs. Figure2-4 [11] shows the example of the dynamic models • Finding behavior patterns, repeating sequences of events • Using static abstractions • Dynamic information is combined with the high-level static model • Apply the approach to extract dynamic model or advanced model [pic] Figure2-4: the example of the dynamic models Analysing the dynamic model should be conducted through these following aspects: • Object creation and related dependencies • Dynamic binding, polymorphism • Method calls • Looking for dead code/reachability analysis • Performance and related problems • Concurrency After we both can automatically generate the static model and dynamic model we can integrate them into enterprise business behavior interface that can abstract the common behavior of the enterprise legacy system, as a result to be an adapter for the platform. 2.2.4 Use case of the system [pic] Figure 2-5: The use case diagram of the system user The use case for the system user is showed in the figure 2-5. From the use case diagram, we could see what the system user can do in the system. We can see from the use case design of the system. It mainly includes the function “excute tracer”, “generate scenario”, “synthesis state machine” and “generate statechart”. Each main function also has the corresponding operation to require the system’s requirement. Excute tracer: Use the program tracer to extract the event trace from the legacy system and output the event trace in appropriate format. Generate scenario: apply the appropriate methodology to analysis the event trace in order to generate the scenario as the input of the synthesis of FSM. Synthesis state machine: apply the corresponding algorithm implemented into the application to transfer the scenario to the state machine. And output the state machine in the appropriate format. Generate statechart: use the corresponding methodology to optimize the FSM to the statechart. Output the statechart in the graph represents the equivalent FSM. 2.3 Brief summary In this section, we mainly discuss about the requirement of the project through the aspects MDA Framework for Reverse Engineering of Software System, Integrating Static and Dynamic, Enterprise interoperability, the origin of the project proposed Harmonized federate structure and the Process of abstracting the dynamic model. It illustrates not only the requirement of the project, but also demonstrates the significant sense to develop the project to abstract the behavior model. And also demonstrate the main goal and content of the project, that automatically or mostly automatically generate dynamic behavior diagram on the condition that already existing the UML diagrams and models based on the MDA framework, through the common abstraction of the target system of enterprise to improves the level of Enterprise interoperability with reliable platform which the different enterprises can apply. Chapter 3 System Design and Implementation 3.1 Overview of the System Design 3.1.1 Development process of the system In this section, we maily demonstrate the general design of the system structure, roughly the system could be divided into three main parts and phases to implementthem respectively. In this section, we maily demonstrate the general design of the system structure, roughly the system could be divided into three main parts and phases to implement them respectively. [pic] Figure3-1: overview of the process of the system design Figure3-1 shows the main process and system develop procedure of the project, apparently we can see from the graph, the entire system development can be proceed through five main phase: applying program tracer to extract the legacy and get the event trace and sequence information from the legacy system, analyzing the event trace and using the scenario editor approach to generate the corresponding scenario diagram, making the scenario diagram as the input of the statechart integrator and evolving the adapted BK-algorithm to generate the finite state machine corresponding to the input scenario diagram, optimizing the finite state machine to the statechart using the synthesis of FSM approach, finally stimulating the timing issue for each state to generate a simple DEVS model. [17] Particularly, the key procedures during the whole development of the system are applying the program tracer precisely obtain the event trace of the legacy system and proceeding the algorithm of the integrator successfully generate the state machine these two phases. In the next several sections of this chapter, we will demonstrate each process and each phase in detail and respectively, the detailed design and plan will be given on each process. Apparently we need a legacy system to start the whole project, we will use it as the experimental example for the proposed project. Therefore we take the typical ATM machine system as the legacy system since the ATM machine system has the distinct and obvious state of each changement of the action. As it is necessary to test a legacy system, we develop a typical ATM machine system implemented in JAVA language. 3.1.2 System structure design [pic] Figure 3-2: The structure of system function design According to the process of the system design, we plan to develop the system into 5 main parts, as you can see in the Figure 3-2, the module “Excute the Tracer” including subsystem “profiler the legacy system”, “collect the statistic of the legacy system”, “output the event trace into XML file”; the module “generate scenarios” includes “generate corresponding scenarios” and “analysis input event trace” subsystem; the module “editor the scenarios”; the module “Generate state machine” includes “input the scenarios in XML file” and “ Generate finite state machine” subsystem; the module “synthesis FSM” includes “input the FSM in XML file” and “Generate the statechart” subsystem. In the following sections of this chapter, I will illustrate the detail design of each module of the system. As in the module “Generate scenarios”, “Generate state machine” and “synthesis FSM”, we need to propose the appropriate methodology and algorithm to implement the function of the module so we will mainly focus on the discussion about the algorithm and methodology which we proposed and as well as the software implementation method of the algorithm in these three sections. The Figure 3-3 shows the subsystem topology of the whole system, in the diagram we define 5 mian subsystem and with the description of each system’s main function. [pic] Figure 3-3: Subsystems topology 3.2 The execution of the event tracer Jprofiler 3.2.1 Tracing the legacy system by program tracer Jprofiler The introducing of the program Tracer: Jprofiler As illustrated in the section 3.1, the first pivotal phase of the whole project is using the program tracer reversly analysis the legacy system. It is necessary to extract the useful statistic from the program in order to identify the event trace of the legacy system. According to the static model, we expect the trace result should include the each method’s usage and it’s time consumption, the original class proceedes each method, the relationship between each class which has called a method. With these statistic combine with the static model information, we could manually or approximately automated generate the event trace of the legacy system. The reason why choose Jprofiler as our program tracer compared to some other tracer software: ➢ With JProfiler you can immediately observe profiling data as your application is running. CPU, memory and thread profiling views are updated live and can be inspected without the need to wait for the measurement to complete. For a large number of use-cases, this ability provides you with an extremely fast path to a solution. In addition, you can save snapshots at any time, interactively as well as programmatically. ➢ Finding a memory leak can be impossible without the mostly profiler tool. But JProfiler's heap walker offers an intuitive interface to solve both simple and complex memory problems. 5 different views show different aspects of the current set of objects. Each view allows us to create new object sets based on the displayed data. Each view provides us with essential insights on the selected objects. ➢ With JProfiler, we can have a decisive advantage when trying to find the reason for a problem. Call tree view filters, aggregation levels and thread status selectors are just some examples of JProfiler's versatility in this area. ➢ Excellent support for Java Enterprise Edition. Dedicated support for JEE is present in most views in JProfiler. ➢ JProfiler also presents high level information about files, sockets and processes within various views. With the time line you get an instant overview of the activity of open connections, files etc. With the hotspots view you can concentrate on the right spots when speeding up your system and telemetries and tracker allow you to monitor your application over time. ➢ Broadest support for platforms, IDEs and application servers. JProfiler integrates into your environment: It provide native agent libraries for a wide range of platforms, both for 32-bit and 64-bit JVMs. [19] And with all this conditions and advantage, Jprofiler is charge software. But fortunately we can apply a Trial version on its official website http://www.ej-technologies.com/index.html, the trial period could up to one month. During the whole project development, we only need to use the tracer at the beginning of the work, so it’s totally enough for us to finish the implementation of the extraction of the legacy system. That is a very important reason why we choose Jprofiler as the program tracer. Execution of the Tracer Jprofiler Figure 3-4 shows the start of the Jprofiler tracking the program successfully, the New session dialog box is running the experimental ATM program, and the figure shows the memory views of the classes, it collected all the objects in the class. And it shows how many instances count each class have as well as its size. [pic] Figure 3-4: the memory view and optional interface of the program Figure 3-5 depicts the function Call tree of the Jprofiler, the call tree shows Show an accumulation of top-down tree, the tree contains all the records access in the JVM queue. From top to down it recorded the method being called in the main Class and the whole program. We can see the sequence of the method be called is according to the option of the changement of the state of the program. Each method has the sub level call tree which record the method invocation during the invocation of itself. Also we can see the call tree record the timing issue each method occupied during its invocation. This information can help us to identify the method call repetition and identify the key method which process during the transition of the state and event changement. We will discuss the approach in the section 3.2.3. using the call tree and call graph to generate or draw the sequence diagram or scenarios of the experimental system. [pic] Figure3-5: call tree of the strat_up of the program Figure 3-6 shows the login state call tree of the program, we can see from the graph the method login after the invocation of the method ATM input. These two methods are the key method of this action event, and also they take the most occupation of the system source. [pic] Figure3-6: call tree of login state of the program Figure 3-7 illustrates the call tree of the state withdraw of the program, we can see except the ATM input method, the withdraw method take the most resource of the system program. It demonstrate the when the state change to withdraw, it took the most system source change is the withdraw operation. [pic] Figure 3-7: call tree of the withdraw option of the program [pic] Figure 3-8: call graph of the ATM withdraw method The figure 3-8 is the call graph of the withdraw method, the call graph display the selected method access to the queue of Figure. It is based on the call tree, but demonstrate the sequence of each method be involved and the position of each method. And also we can see from the graph the method call repetition by different methods. And maybe recursive methods call occurred and shown in the graph. Combine the information of the call graph we will disscuss in the next section using the proper approach to generate the sequence diagram or scenarios of the system. Figure 3-9 shows the call graph the main Test method with withdraw operation it shows the related method occurred in the whole process sequentially. We could get the sequence and the timing relationship of different methods, as noted the method call depicted in the call graph hierarchically.[21] [pic] Figure 3-9: call graph of the main Test method with withdraw operation 3.3 Editoring the event trace to scenario diagram 3.3.1 Generation of scenarios overview This section mainly demonstrates the approach to construct the sequence diagram (scenarios) from the information and statistic we have already extracted from the target system by program tracer Jprofiler which we discussed in the last section. Our method starts from getting an execution trace of method calls of the target software system. We propose four compaction rules to reduce the amount of information since the amount of the trace is very huge. The rules compact the execution trace by abstracting some repetition patterns and recursive calls included in the trace. The compacted execution trace is translated into a compact sequence diagram. Our compaction method preserves almost the structure of the original information. Therefore, we can see which instances are interacted and how the function is implemented in the generated diagram. Since the original trace information is preserved, we also can see the uncompacted original sequences. We expect that our method is useful for understanding of the program behavior in the maintenance phase. Figue 3-10 illustrate the class diagram of this implementation for this module to generate scenarios. It is the entire design of the scenario generation design in the implementation view. [pic] Figure 3-10: Class diagram of generating scenarios from event trace module To explain each rule, we use a call tree which expresses a method call structure recorded in an execution trace. A node of a call tree represents a method call and has the method signature and ID of the callee object. 3.3.2Compaction of Repetitions First we give the class and implementation design for the compaction of repetitions. It is according to the overview class diagram of the generation statechart. The class diagram is shown in Figure 3-11. [pic] Figure 3-11: Class Diagram of the Compaction of Repetions In this section, we will illustrate the rule Rule1 (R1), Rule2 (R2) and Rule3 (R3) which compress the some kind of repetition patterns. They detect a repetition of similar subtrees in a call tree, and they may replace such subtrees with one representative, which shows the entire repeated structure and the number of the repetitions. The differences of each rule are which subtrees considered to be similar and how to make a representative. ➢ The rule R1: Completely same The rule R1 shows a repetition of completely implements the same method call structure, and also depicts the method to compacts it. So, R1 considers subtrees to be the same, if subtrees have the same structure and also their nodes have same methods and objects. The rule R1 uses first one repeat unit as the representative of them. Since the representative records the number of times of the repetition, R1 does not lose information. [22, 23] ➢ The rule R2: Allowing different objects The rule R2 shows a repetition of method call structure whose object IDs may be different, and also shows the method to compacts it. In other words, R2 considers subtrees to be similar, if subtrees have same structure and their nodes have same method. R2 does not compare object IDs. To replace with the whole of the repetition, R2 makes the representative by unifying the object IDs (Figure 3-12). [pic] Figure 3-12: Making the representative by R2 R2 can compact subtrees which cannot be compacted by R1. However, since the result of compaction of R2 has some method calls to unified objects, it can not represent the original execution trace accurately. ➢ The rule R3: Lack of method calls The rule R3 illustrates a repetition of method call structure some of this whose method calls may be lacked (Figure 3-13), and the method to compacts it. Lacked means that, in comparing two subtrees, a method call which contained in one subtrees does not appear in the other one. R3 take into account subtrees to be similar, if some method calls are lacked in one of the subtrees compared with the other subtrees. R3 builds the representative of the repetition based on the non-lacked subtrees (at least one non-lacked subtrees are included in the repetition), by unifying the object IDs and marking the lacked methods (Figure 3-13). [pic] Figure 3-13: Making the representative by R3 Since R3 can compact some repetitions whose structures may be different every one time, R3 compacts an execution trace, rather than R2. But, the result of compaction of R3 has some lacked method calls, so it does not represent the original execution trace accurately. 3.3.3 Compaction of Recursive Calls In this section, we describe the rule R4 which compacts recursive call structures. The rule R4 detects recursive method calls, and compact the structure. We consider that the call of the same method to different objects is also to be recursive calls. [24] The processes of R4 are the followings. First, we find a method which is called recursively and separate the call tree at the nodes of the recursively called method. Next, we make a set of the separated subtrees, whose elements are not lacked from any other subtrees which are not contained in the set. Finally, by connecting the trees contained in the set, we rebuild the call tree which shows the compact recursive call structure. [12, 25] 3.3.4 Drawing Sequence Diagram First we give the class and implementation design for the obtaining of sequence diagram. It is according to the overview class diagram of the generation statechart. The class diagram is shown in Figure 3-14. [pic] Figure 3-14: class diagramof the generation of the Scenario The compressed execution trace will be translated into a sequence diagram. We could define annotation symbols for each compaction rule to indicate compacted part of the sequence diagram. Here, we explain the annotation symbols with examples. [pic] Figure 3-15: A generated diagram of a part compacted by the rule R1 ➢ Annotation for R1 We depict the instance of fragment of the sequence diagram in Figure 3-15. In this example, the method b() of the instance B(2) is called twice during the execution of the method A(1).a(). R1 replaces the two method calls with one method call and adds an annotation sym- bol to the left side to indicate the repeated segment and the number of repetitions. [26] ➢ Annotation for R2 The instance of fragment is shown in Figure 3-16. In this example, the method b() of the instance B(2) and the same method of the instance B(3) are called in sequential order. R2 replaces the two instances with one unified object B(2, 3) and adds an annotation to the object of the diagram to indicate the unified object. R2 also adds an annotation to the left side of the repeated segment, the repetition is represented the same as R1. [pic] Figure 3-16: A generated diagram of a part compacted by the rule R2 ➢ Annotation for R3 The instance of fragment is shown in Figure 3-17. As for this example, the instance B(2) calls the method c() of the instance C(4) and the instance B(3) doesn’t call the method c(). R3 do replace B(2) and B(3) with the object B(2, 3), and R3 unifies the two executions of the method b() as one execution whose the method c() may be not called. So, R3 adds an annotation to demonstrate such a method. R3 also uses annotations representing repeated phases and unified objects for R1 and R2. [26] [pic] Figure 3-17: A generated diagram of a part compacted by the rule R3 ➢ Annotation for R4 The instance of fragment is shown in Figure 3-18. In this example, we could see that the method a() of the instance A(1) is recursively called. R4 represents a block of the recursive calls and replaces the block with a box. The box is annoated with the name of the method recursively called, and a recursive call is represented as a method call to the block. [27] [pic] Figure 3-18: A generated diagram of a part compacted by the rule R4 3.3.5 Evaluation We give the class and implementation design for this evaluation module. It is according to the overview class diagram of the generation statechart. The class diagram is shown in Figure 3-19. [pic] Figure 3-19: the class diagram design of the Evaluation method In the evaluation phase, we evaluated the proposed method through two different experiments. First one evaluates the compaction ratio of the four execution traces. Second, we try to implement a program with the function by using only our tool and source code. We extracted the four execution traces and compacted them with four compaction rule. Since R4 compacts recursive calls and makes other rules effective, we applied R4 first. After applying R4, other three rules were applied from a strict compaction rule. The target programs, size of the execution traces and the results of the application of the rules are shown in Table 3-1. In order to evaluate the effectiveness, we define Compaction Ratio. We say that compaction is more effective when the compaction ratio [16, 28] is smaller. Compaction Ratio (CR) = Method call count after applying the four rules ×100% Table 3-1 sizes of the applications of the rules [pic] We could see the result, the compaction ratio which is the highese reach 0.85%. The size is greatly reduced from original size. The compaction ratio of LogCompactor is 0.88%, and the actual size is 105 method calls. The size is small enough for programmers to read the meaningful information from the compacted trace. The compaction result of scheduler is 147 method calls, this is also small enough to read the execution trace. On the other hand, the compaction ratio of jEdit is 7.22%. The compacted trace includes several complex repetitions which are not handled by our four rules. In the future work, we will examine further rules to handle such repetitions. In the case of the execution trace of jEdit [29] which has the largest number of method calls, the compaction process took about five minutes. It is practical since the compaction process is performed only once. The diagram generated from scheduler is shown in Figure 3-16, Figure 3-17, Figure 3-18 and Figure 3-19. A generated diagram contains the compacted repetitions identified by the proposed rules. The scenario diagram or sequence diagram generated respectively through the approach present in the Figure 3-20, Figure 3-21, Figure 3-22 and Figure 3-23 with different interactions. [pic] Figure 3-20: Interaction with an ATM (SD1) Figure 3-20 illustrates the interaction of the bad account option with ATM machine system. It shows the show and events trace of this option, according to the rules we discussed before we manually construct this scenario. This may not be extremely accurate, but generally it could represent the main sequence and event trace of the target ATM system. [pic]Figure 3-21：Interaction with an ATM (SD2) Figure 3-21 illustrates the interaction of the bad password option with ATM machine system. It shows the show and events trace of this option, according to the rules we discussed before we manually construct this scenario. [pic] Figure 3-22：Interaction with an ATM (SD3) Figure 3-22 illustrate the interaction of the withdraw option with ATM machine system. It shows the show and events trace of this option, according to the rules we discussed before we manually construct this scenario. [pic] Figure 3-23：Interaction with an ATM (SD4) Figure 3-23 llustrates the interaction of the transfer option with ATM machine system. It shows the show and events trace of this option, according to the rules we discussed before we manually construct this scenario. We tried to understand how a program’s function was implemented. The function which we tried to understand was the file loading function of jEdit. In this task, we used only our tool and source codes without referring to any documents and any websites. As the result of the second process, we confirmed the ffectiveness of our method. The compacted sequence diagram can be easily understood rather than the non-compacted original diagram, and the important method call information which we need to understand is not lost at all. [13](ex. all method calls occurred in repetitions, objects received method calls and interactions of them were indicated.) he compaction process will be performed only once per an execution trace; after that, the tool can display any parts of sequence diagram of the trace. We think that processing that time affordable in practice. 3.4 Algorithm Design for synthesizing state machine In this section, we main demonstrate the approach to synthesis the state machine from the scenario diagram, particularly illustrating the algorithm constructed and applied in the statechart integrator. Actually the algorithm carried out to implement the synthesis of the state machine is the most important and key phase through the whole project. With the utilities of the adapted algorithm we propose, we mostly could transfer the model from static to the dynamic. It is a transmission between different levels and also implements the abstraction of the business behavior of the target system. Consequently, the obtained statechart could appropriately represent the business behavior of the target system or generally apply to the enterprise’s software system. 3.4.1 The BK-algorithm Since our approach is based on the BK-algorithm to make some improvement and adjustment in order to support our system and our interest, we first introduce some notations and definitions related to Biermann’s algorithm. As the Biermann present their algorithm (BK-algorithm) for synthesizing programs from their traces [30]. The idea of theiralgorithm is that the user specifies the data structures of a program and describes (graphically) its expected behavior in the case of an example input in terms of primitive actions (like assignments) and conditions that hold before certain actions. Actually, the user gives traces (i.e., sequences of actions and conditions) of the expected program, and the algorithm produces the smallest program that is capable of executing the given example traces. Furthermore, after giving some finite number of example traces taken from a program, the algorithm produces a program that can execute exactly the same set of traces as the original one, that is, the algorithm learns (or infers) an unknown program. Before discussing the principles of the BK-algorithm and studying its properties, it is necessary to introduce the notation used and definitions related to it. A computation consists of condition-instruction pairs rt = (ct, it) being executed at discrete times t = 1, 2,... . Instruction it operates on memory contents mt−1 resulting in a new memory con- tents mt; this is denoted by mt = it (mt−1). Branching is made possible by using conditions that are (possibly empty) conjunctions of atomic predicates or their negations. The value of condition ct on memory contents mt−1 is denoted by ct(mt−1). The value of the empty condition φ is true. The validity of condition ct is checked before instruction it is executed.[30, 31] Instructions available are denoted by I0, I1, I2,..., Iz , and IH , where I0 denotes the start instruction and IH is the halt instruction. Every program has exactly one occurrence of I0 and usually one occurrence of IH. An instruction may appear several times during a computation. The appearances are separated by labels. For example, the appearances of I1 are labeled by 1I1, 2I1, 3I1... A partial trace T of a computation is a (2n + 1)-tuple T = (m0, r1, m1, r2, m2... rn, mn), where, for each t = 1, 2, 3,..., n, we have rt is a condition-instruction pair rt = (ct, it), mt = it(mt−1), ct(mt−1) is true, and c1 = φ. A trace is a partial trace T = (m0, r1, m1, r1… rn, mn) with the additional requirements that r1 = (φ, I0) and rn = (cn, IH). An incomplete program P is a finite set of triples of the form (qj, ck, qe), where each qj and qe is a labeled instruction and ck is a condition, and where the fol- lowing restriction holds: If (q, c, q’) ∈ P and (q, c’, q’’) ∈ P and there exists m such that c(m) = c’(m) = true, then c = c’ and qt = q’’. A program is an incomplete program with the additional requirements that 1. Each program has exactly one start instruction, namely 1I0, and (1I0, c, q) ∈ P , for some c and q. 2. If there is a transition (q, c, p), where c is a non-empty condition, then there must also be transitions from q for every possible combinations of the atomic predicates and their negations presented in c. Programs can be illustrated as directed graphs with instructions as nodes and transitions as edges. Edges are labelled with conditions. So, empty conditions correspond to unlabelled edges. Figure 3-24 illustrates a program with transitions (1I0, φ, 1I1), (1I1, {a}, 2I1), (2I1, φ, 1I2), (1I2, φ, 1I1), and (1I1, {¬a}, 1IH ). [32] [pic] Figure 3-24: Program P = {(1I0, φ, 1I1), (1I1, {a}, 2I1), (2I1, φ, 1I2), (1I2, φ, 1I1),(1I1, {¬a}, 1IH )}. A Java version of the program in could be written as shown as following: public class X { … public void exampleMethod() { I0(); I1(); while (a) { I1(); I2(); I1(); } IH(); } … As for the input, the input of the BK-algorithm is a set of traces from, the traces of the algorithm infers a program consistent with the traces. The algorithm defines a minimum labeling for instructions given in these input traces. This means that the number of different instances of an instruction in the resulting program, and hence the number of nodes in the directed graph illustrating the resulting program, are minimized. Consider two labelings of n instructions, say U = (u1, u2,..., un) and V = (v1, v2,..., vn). [32, 33]We denote U < V , if there is j, 1 ≤ j ≤ n, such that ui = vi, for i = 1,...,j − 1, and uj< vj . Let k be the number of different instances of instructions in the corresponding program (i.e., k is the number of nodes in the directed graph that represents the program). The rank of labelings is defined for pairs of the form (k, U). If (k, U) and (k’, U’) are two such pairs, we denote (k, U) < (k’, U’) if k < kt or if k = kt and U < U t. Hence, one starts with a pair (1, (1, 1,..., 1)) and enumerates all the pairs (k, labeling) in increasing order, until a pair that defines an incomplete program is found. This process will always halt, since the pair (n, (1, 2,..., n)) defines a linear program with no branching or loop. As an example, consider the trace (m0, (φ, I0), m1, (φ, I1), m2, ({a}, I1), m3, ({a}, I2), m4, (φ, I1), m5, ({¬a}, IH ), m6). Since the trace contains four different instructions (I0, I1, I2, IH ) it is useless to try values less than k = 4. The only possible labeling with k = 4 is (1, 1, 1, 1, 1, 1). This labeling would give transitions (1I0, φ, 1I1), (1I1, {a}, 1I1), (1I1, {a}, 1I2), and (1I1, {¬a}, 1IH ). This set of transitions contradicts the requirements of determinism (transitions (1I1, {a}, 1I1) and (1I1, {a}, 1I2). Hence, we set k = 5. Labeling (1, 1, 1, 1, 2, 1) implies nondeterminism as well, but labeling (1, 1, 2, 1, 1, 1) gives the program illustrated in Figure 5.1. [35] We say that a program P can execute trace (m0, (c1, i1), m1, (c2, i2), m2,..., (cn, in), mn) 3.4.2 Adapted algorithm for synthesizing state machine In this section we mainly discuss about the algorithm we use to synthesis the state machine from the editored scenario diagram, firstly we illustrate the comparison between the adapted algorithm we used and the BK-algorithm to see the connection and difference between them. The core theory and methodology we take from the BK-algorithm, and we make some improvement and modification to adapt the experimental environment which we take. The shortage and limitation of the BK-algorithm especially for our experimental environmental: • Although BK-algorithm’s notion of a program is clearly related to OMT’s state machine, the relation is not trivial. • Can not deal with a sequence of repeated attempt of events • framework actions are simple statements of a program(not high-level) • Can not avoid unnecessary attempts if the initial approximated state number is close to the real one. • Doesn’t work in an incremental mode (i.e. the traces can be given to the algorithm one by one, and synthesized into the existing state machine). Consequently based on the core and key theory of the BK-algorithm, it is necessary to make some improvements and propose an adapted BK-algorithm to adjust the requirement of the experimental environment. We will discuss about the idea that adapt the BK-algorithm, [31] first of all we will define a concept corresponding to Biermann’s trace. Let F be the set of events in system S. We suppose that all systems have two special events called default and null in their event sets; default is an event that is considered to occur at any time and null is an event that never occurs. A default event corresponds to an empty condition of Biermann’s method. We require that in a state machine a transition associated with this event is the only leaving transition of its source state. A trace in S is a sequence of pairs (t1, t2) where both t1 and t2 are elements of F. (We adopt this term from Biermann’s method although the concept is not exactly the same.) Let D be a trace diagram describing a scenario in S with an instance of class C. The trace originating from diagram D with respect to C is obtained as follows. Consider the vertical line corresponding to the C object in D. If it is necessary, augment the trace diagram with additional entering default arcs or leaving null arcs for C so that the C column consists of an alternating sequence of leaving and entering arcs, starting with a leaving arc and ending with an entering ‘null’ arc. Starting from the top, for each two successive events t1 and t2 associated with C; add item (t1, t2) into the trace.[30] We define the concatenation of traces in the obvious way: if T1 is trace (a1, b1) … (am, bm) and T2 is trace (c1, d1) … (cn, dn), then T1T2 is trace (a1, b1) … (am, bm) (c1, d1) … (cn, dn). An item of the trace (t1, t2) shows that, during the execution of the system, the object sends event t1 to some another object and then responds to event t2 which sent by another object. From the OMT [15] point of view, trace item (t1, t2) means that the execution has reached a state with state action ‘do: t1’ (send event t1) and with a transition labelled by t2 (receive event t2). If t1 is null, the do-action is missing, and if t2 is null, the transition is missing (end of the trace). If t2 is default, there is a default transition from the state. It should be emphasized that actions are by no means state labels. Thus, there is no concept of a state in trace diagrams. Different states may very well have the same action. In a practical system it might be reasonable to allow also state labels in traces (indicating that certain trace items must originate from the same state); we will discuss this in the next section. Note that we make use of guards already in the trace diagrams (see Figure 3-18). When viewed from the receiver’s side, we regard a guard as a part of an event: e [g1] and e [g2] are simply different events from the receiver’s point of view. From the sender’s point of view a possible guard is ignored. We say a state machine M can execute trace T from state q if there is a path starting from q and matching with T. Formally, a path starting from state q coincides with trace T if either T is empty or T = (b, e) T’, q is associated with action b, there is a transition from q with event e to state q’, and there is a path starting from q’ which coincides with T’. M can execute trace T if M can execute T from the initial state; in that case T is called a complete trace of M. [14, 31] In the synthesis algorithm given below, we assume that there is an unknown state machine M whose traces are given as input to the algorithm. At least one of the input traces is assumed to contain the start action. The output of the algorithm is a (deterministic) state machine M’ which is able to execute all the given traces. [21] Furthermore, under certain assumptions (we will discuss these after giving the algorithm), given some finite number of input traces, M’ becomes a minimal state machine such that M can execute trace T if and only if M’ can execute T. Hence, the guess provided by the algorithm becomes functionally equivalent with the original state machine after some finite number of sample traces—the algorithm identifies M in the limit. These arguments follow directly from the results of Biermann and Krishnaswamy. For the purposes of the synthesis algorithm, we define a state machine as a 6- tuple (S, E, A, d, p, I), [35] where S is the set of states, E is the set of events, A is the set of actions, d is the transition function d:S×E → S, p is the action function p:S → A and I c S is the initial state. The transition function defines the next state on the basis of the current state and the event, and the action function associates a (possibly empty) action with every state. We require that p(I) = start, for all state machines. In the algorithm below, we make use of stack G which can store 4-tuples of the form (I’, S’, d’, p’) where i’ is a trace item index, S’ is a set of states, d’ is a partial function d’: S× E → S and p’ is a partial function p’: S → A. The purpose of the stack is to store the so-far computed state set, transition function and action function, to be restored when the algorithm backtracks. The function sta associates a state with each trace item. The set Used(t) gives the set of states so-far considered for trace item t. Algorithm adapted BK-algorithm (State machine synthesis) Input Traces T1, T2 …,Tk of (unknown) state machine M. Output State machine M′= (S, E, A, d, p, I). let T= T1T2…Tk=t1…tm=(a1,e1)…(am,em) (m>0); let E={e| (a,e)∈ T}, A={a|(a,e) ∈ T}; SetEmpty (G); MAX : = card(A) − 1; while true do begin if IsEmpty( G) then i:=1; let p be undefined for all states; let d be undefined for all states and events; S :=φ; MAX:= MAX+ 1 else (i,S,d,p):= Pop(G); —restore previous situation end; let Used (tr) =φfor i ＜r≤m； Undefined sta（tr）for i ≤r≤m； While i≤m do begin If i＞0 and d(sta(tt-1), et-1) = s then —d(sta(tt-1), ei-1) is defined If p(s) = ai then –this is already covered Define sta(ti) =s; i:= i+1; else exit —backtrack end else if d(sta(ti-1), default) is defined or (d(sta(ti-1), e) is defined for some e ≠ default and ei-1 = default) then exit end; —(sta(ti-1) cannot have this transition, backtrack) Cand :={s∈S\Used(ti)|p(s) =ai}; If I ＞0 and Cand ≠φ then —add a new transition push(G(i,S,p,d)); —save this situation in stack pick up a member s of Cand; Used(ti) := Used(ti) ∪ {s}; Define d(sta((ti-1), ei-1) = s; i:= i + 1; else if card( S) ＜ MAX then —add a new state create new state s; S := S ∪ {s}; define p(s) = ai; define d(sta(ti-1), ei-1) = s; define sta(ti) = s; i:= i + 1; else exit —backtrack end; end; end; end: —while i if i ＞ m then exit end; —success! end; —while let i = s such that p(s) = start. 3.4.3 Conclusion of the Adapted BK-algorithm The algorithm we proposed ased on the BK-algorithm following the basic ideas of Biermann (BK-algorithm). It implements the synthesis as a sequence of repeated attempts, each increasing the maximal state number: if there is no way to associate the trace items with states using the allowed number of states MAX, the process is repeated for MAX+1. In contrast to the treatment of Biermann, we use the number of different actions as the initial approximation for the number of states; this is clearly a lower bound. Moreover, it seems that in those applications we have in mind the number of states is usually close to the number of actions (provided that every state is associated with a non-null action). In our case the actions are conceptually high-level since they are part of a relatively abstract characterization of an object’s behaviour, whereas in Biermann’s framework actions are simple statements of a program (like variable assignments). High-level actions tend to be more bound to the ‘state’ of an object than the fairly arbitrary low- level statements. Note that the algorithm avoids unnecessary attempts if the initial approximated state number is close to the real one. Compare to the origin BK-algorithm, the adapted algorithm has the improvement mainly in: ➢ It can be easily modified to work in an incremental mode, i.e. the traces can be given to the algorithm one by one, and synthesized into the existing state machine. We omit the incremental version here. ➢ It is sensitive to the order of traces in its input. Indeed, there are some special cases where the state machine produced may vary depending on the order of the input traces. 3.5 Implementation of synthesizing state machine 3.5.1 Synthesis of state machine from scenarios This section we mainly discuss about the synthesis of the state machine from scenarios based on the experimental example ATM system we execute. As see in section 3.1, we already executing the program tracer on the legacy system and then through the editor scenario approach we get the scenarios of the experimental ATM system. Therefore the next process is applying the appropriate algorithm proposed in the section 3.4 in the statechart integrator to generate the state machine from the scenarios. In this section we particularly illustrate the approach and methodology to implement the synthesis of state machine from scenarios. Figure 3-25 illustrates the class diagram design for the generating the state machine from scenarios. With gathering data information from the requirements specification and the implementation of the algorithm design, we could draw a structure model about the core data model of this module. From this we could get the essential relationship between these entities. [pic] Figure 3-25: The Class diagram design of synthesizing state machine As we discussed, in a scenario, the more accurate in its representation as a sequence diagram, a number of messages exchanged between objects. Each message is a collection (Pijk, M, N), in collection each element indicate the following information: ➢ Pijk illustrates a message derive from object i and enter object j, k is used to indicate the different messages between objects; [15] ➢ M indicates the name related to the message; ➢ N indicates the type of transferred message, and it has the parameter of the following values: -1, 0 or 1. In our case “-1” represents simple message, 0 represents synchronous message and “1” represent asynchronous message. Consequently, in our approach a scenario will be a set of collections including all the messages which get exchanged between all objects of that scenario. [16] Related to our experimental ATM example and also the method to generate the scenario which demonstrated in the 3.4, we could consider our experimental ATM system for representing the scenario in set of collections, we take one scenario of experimental ATM system, (illustrated in Figure 3-26) in the example, there are 4 objects are included: User, Bank, ATM and Bank Consortium that Represented in O1, O2, O3 and O4 respectively. For our experimental example the message is transferred as follows: “display main screen”, “insert a card”,”request the password”, “enter the password” and so on. Consequently, for the scenario, after option “insert card” and “insert the password”, then the ATM need to verifie the card with the bank consortium. The bank sends a bad bank account event to the consortium, and the consortium sends a bad account event to the ATM. The ATM, vice versa, sends a bad account message event to the user. Finally, a receipt is generated. As demonstrated above the experimental example scenario S0 will therefore have the following set of collection: [16] S0= [(P321, Display_main_screen, 0), (P221, Insert_card, 0), (P232, Request_password, 0), (P312, Enter_password, 0), (P131, Verify_account, 0), (P142, Verify_card_with_bank, 0), (P331, Bad_bank_account, 0), (P311, Bad_account, 0) , (P213, Bad_account_message, 0), (P211, Print_receipt, 0), (P255, Eject_card, 0), (P126, Request_take_card, 0), (P143, Take_card, 0),(P357, Display_main_screen, 0)]. As we can see from the scenario, there are 4 objects involved in this scenario; we can get 4 state machine diagrams for each object. [16] In a perfect description of the experimental system, there are K scenarios, with a total number of Q objects. Based on the approach we use, we will have K sets of collections which including all the transitions between objects. [pic]Figure 3-26: Scenario diagram of an ATM system Consequently, the total number of the state machine diagrams will be equivalent to the number of objects in all scenarios. So, we will have a number of Q state machine diagrams. [14] 3.5.2 Approach of synthesis As to the class diagram design of the entire synthesis state machine, now we give the each part’s class implementation design. Figure 3-28 shows the class design of Synthesis. [pic] Figure 3-28: the class diagram design of the synthesis approach As the description and representation of the scenario is already done in the section 3.5.1, the next setp is to generate the state machine diagrams for all objects, our approach proposes the following setps: [16] ➢ To identify and represent all single scenarios; ➢ To identify and indicate the relationships between all the scenarios we obtained; ➢ Based on the information obtained in the previous two phases we depicts before, Synthesize the state machines diagrams. ➢ Creating one initial state machine diagram for each scenario,this scenario have the appearance of the object; ➢ Based on the information we obtained in the scenario diagrams. Synthesizing the final state machine diagram from all the initial state machine diagrams. 3.5.3 Establishment of initial state machines As to the class diagram design of the entire synthesis state machine, now we give the each part’s class implementation design. Figure 3-29 shows the class design of Creation State machines. [pic] Figure 3-29: the class diagram design of the initial state machines creation We will demonstrate briefly how to get these state machines. State machines are the ones that relate events and states. In the approach, for the current state an event is received, then the next stateaccording to the current state. The transition is a change of state caused by an event. When a transition is triggered, the system releases its current state, to the next state proceeds the actions specified for the transition and set it in a new state. Based on [17], we will identity the basic principle for synthsizing state machines from the single scenarios: In our approach for the ATM experimental system, the amount of initial state machines for an object Oj like “bank consortium” will be equivalent to the number of scenarios like Figure 3-26 shows in which the object Oj is proceeded. While, overall the description in our approach the steps of creating initial state machines are as follows: ➢ Setp 1：Construct an empty state machine diagrams. For our experimental example we proposed only one scenario, the one in Figure 3-26, this step will only create one empty state machine diagram. After obtaining the final state machine diagram for ATM, we launch the same method for the other objects, User, Consortium and Bank. ➢ Setp2: according to the method in 3.5.2, create all events which corresponding to transitions to the object for each state machine; According to our approach in 3.5.2, we create all events which corresponding to transitions to the object. In our instance, as we can see from the scenario it already creates Insert card, Enter password, Bad account, and Take card. ➢ ➢ Setp 3: For each transition that from the each object, we will create actions that conduct to the corresponding states and create the correct state; In this step we depicts that the actions that conduct to states are created, specifically the action is Display_main_screen, Request_password, Verify_account; Bad_account_msg. Print_receipt, Eject_card and Request_take card. Those States with the same names are created at this time also. ➢ Setp4: Compare to the scenario obtained in the last section, we record the time sequence of the transition and store the time order in the each state of the object. After the extraction of step 1-3, the problem is transitions have not been seted into the right time sequence. So in setp 4 for all transition the source and the destination is established, so that all transitions will be related with a starting point and an end point. Figure 3-30 demonstrates the state machine diagram corresponding to the experimental example ATM object in the obtained scenario which given as example in Figure 3-26. [pic] Figure 3-30: State machine diagram for object ATM 3.5.4 Synthesis of final state machines [pic] Figure 3-31: the domain design of the synthesis of final state machines As we discussed in the section 3.4, according to the adapted BK algorithm we managed to give the class diagram design of the “synthesis of the final state machine: module as shown in the Figure 3-31. Considering we already creat the initial state machine in the section 3.5.3，the next step is to generate the final state machine of the system. In this case, we need to combine all the initial state machines which we obtained and make use of the scenario diagram. As it is already depicted before, based on the classification of relationships [21] between the different scenarios, there are some rules that need to be obeyed: ➢ Rule1：In a set of two scenarios, the resulting state machine diagram combines the two basic state machine diagrams. ➢ Rule2：If a transition is general for two scenarios, it will be used only once in the final state machine. ➢ Rule3： If it is two scenarios associated with a different relationship, their corresponding state machines should be merged in OR. ➢ Rule4：If two scenarios are proceeded at one time, their corresponding state machines need to be merged in AND. To illustrate our idea, we condier the experimental example of our approach we take into account 3 scenarios of using the ATM: withdrawing cash, depositing cash and transfer money,and for each of them the scenario is Scenario_withdraw, Scenario_deposit and Scenario_transfer. The entering common scenario shows in Figure3-32, while the other three scenarios shows in Figure3-33. [pic] Figure 3-32： Scenario Scenario_start for ATM system However scenario Scenario_start excutes the other three scenarios, Scenario_withdraw, Scenario_deposit and Scenario_transfer, these are associated by separation, and only one of the scenario can take place at a certain time. Consequently, we want to obtain the state machine corresponding to object ATM. There are 4 scenarios in this corresponding scenario; so, we will have 4 initial state machines for representing, demonstrated in Figure 3-34. [pic] [pic] Figure 3-33：Scenarios Scenario_withdraw, Scenario_deposit and Scenario_transfer for ATM system [pic] [pic] [pic] [pic] Figure 3-34: Initial state machines for object ATM, each corresponding to one scenario [pic] Figure 3-35： State machine diagram for object ATM According to the obtained scenarios in the section 3.5.3, demonstrating the association between them, we managed to get the state machine diagram in Figure 3-35. 3.6 Generation of statechart from representation of FSM This section mainly illustrates the approach to transfer the finite state machine (FSM) to the statechart. As given by the section 3.5, we have already generated the FSM of the experimental ATM system. Here we give some notation for the FSM, and also the purpose and basis of acknowledge proposing this methodology. Figure 3-38 illustrates the domain design of this module of the entire system. It is division into 4 main parts to implementation: “FSMAnalysis”, “Decomposition FSM”, “Statechart Extraction”and “StatechartAnalysis”. In the following context of this section, I will illustrate each domain’s detail design. [pic] Figure 3-38: the class diagram design of the generation of statechart module The Finite State Machines (FSMs) which we obtained in the previous setp from the scenario are the classical state modeling that are extensively being used lots of application areas, behavior description, analysis, synthesis of software, generation of test cases and test coverage analysis being some of the prominent ones. Though FSMs are easy to use and are very intuitive, they suffer from several shortcomings. A very severe shortcoming of FSMs is commonly referred to as the state space explosion problem [11]. The complexity of an FSM model increases dramatically as the number of state variables increases. Since many software developers are well acquainted with the classical FSM formalism, during construction of state models they often end up developing the FSM model of a design element rather than its statechart model. Also, during the reverse engineering of legacy code, an FSM model is naturally constructed rather than a statechart model [13]. In several such situations where it becomes necessary to extract the equivalent statechart models from FSM models. Such extraction can help in several ways such as enhancing the understandability of model behavior [21]. Besides, many existing work use statechart models to automatically generate test cases [10] and code generation [17], etc. These methods can be used if the statechart model can be obtained from the FSM model. A few reported researches address an extraction of hierarchical state model from FSMs [5, 12]. However to the best of our knowledge, we could not find any research report addressing the extraction of statecharts from state models in the absence of other model views, such as class diagram, collaboration diagrams etc. We present a method based on decomposition [14] to extract an equivalent statechart from FSM. 3.6.1 Example of FSM As the entire class diagram design shown in the last section, here we give each corresponding class design to each part.Figure 3-39 shows the class design of the FSMAnalysis. [pic] Figure 3-39： the class design of the FSM analysis An FSM can be used to represent the different states that an object may assume and the transitions among the states. We represent an FSM (M) as M =(S, S0, T , δ), where S is the set of states, S0 ∈ S is the initial state, T is the set of transitions and δ:T × S → S is the next state function. The initial state of an FSM is represented by a filled circle. An example FSM is shown in Figure 1. The FSM of Figure 3-40 has six states. In the FSM, transitions among states are annotated with different labels ti∈ T representing the events causing the transitions. State S2 is the initial state. The system starts in the initial state (S2) and if the event t1(t5) occurs, it moves to state S4(S1). Similarly, the system can transit to different states, depending on specific event occurrences.[25] [pic] Figure 3-40: An Example FSM 3.6.2 Statechart analysis As the entire class diagram design shown in the last section, here we give each corresponding class design to each part.Figure 3-41 shows the class design of the StatechartAnalysis. [pic] Figure 3-41: the class design of the statechart analysis There are two kinds of composite states: An OR state contains a complete statechart diagram. When an OR state is active, then one and only one of its component states is active. Figure 3-42 shows a statechart diagram, in which B is an OR state. An AND state consists of several and compartments [11] separated by dashed lines. Each and-compartment may contain a complete statechart diagram or a simple state. When an AND state is active, all statecharts contained in the corresponding and-compartments are active concurrently. Figure 3-42 shows a statechart diagram in which C is an AND state. [25, 26] The initial state in a statechart is represented by a filled circle. Transitions among states are annotated with labels of the form e[c]/a meaning the following. If an event e occurs and the guard c holds (i.e. evaluates to true), then the transition would fire resulting in action a being carried out before reaching the destination state. In Figure 3-42 [21], if the system is in state S1 when the transition e[c]/a fires, then the system transits to state S3. If the system is in any of the states S3, S4, S5 when transition f[d]/b fires, then it will transit to state S2. If the system is in state S2 and the transition e6 [c6]/a6 fires, then the system will assume both states S6 and S8 at the same time and from these the system may transit concurrently or sequentially to state S9 and S7 depending on the occurrence of the events e5, e4 and conditions c5, and c4. Finally, it will transit to the simple state S2 on occurrence of the event e7, if c7 holds. In my research we assume that a statechart consists of simple states, OR states, AND states and initial states. Further, we assume that the annotations on transitions consist of events only. That is, we do not consider guard conditions and actions in our work for simplicity. However, these aspects can be easily handled through a trivial extension to our work. [pic] Figure 3-42: the experimental example of the statechart 3.6.3 Decomposition of the FSM [pic] Figure 3-43: the implementation design of the Decompose FSM Decomposition of an FSM implies expressing the FSM in terms of several simpler FSMs (subFSMs). These subFSMs become the component FSMs of and-compartments of an AND state in a statechart. This AND state with these component FSMs should be semantically equivalent to the original FSM. These subFSMs are referred to as the partitions of the original FSM. An important step in extracting an equivalent statechart from a given FSM is to decompose it into subFSMs. These subFSMs become the component FSMs of and-compartments of an AND state in an equivalent statechart. A partition on the set of states S (S ={S1, S2, · · · , SN }) of an FSM is a set of disjoint and nonempty subsets of S whose union is S. Let A = {A1, A2, · · · , An1} and B = {B1, B2, · · · , Bn2} be two partitions satisfying the decomposition constraint, i.e. each transition t ∈ T of the FSM maps subsets of A (B) into the subsets of A (B). [7, 10]These partitions can be used to find the subFSMs. The decomposition of FSM (Figure 3-40) into two subFSMs is shown in Figure 3-42. This decomposition process can be generalized to partition an FSM into any number of subFSMs. [15, 21] The two subFSMs MA and MB of a composite state, corresponding to A and B are defined as follows: The states of MA are the subsets of A. The transitions TA for MA are drawn from T such that each transition t ∈ TA occurs on all the states of Ai ∈ A, for i ≤ n1. More precisely, we have MA = (A, A0, TA, δA) , where A0 is the subset of A which contains S0. The next state function for MA, δA : A × TA → A is defined such that δA(Ai, t) = Aj , if and only if δ(t, si) = sj , ∀si∈ Ai and ∀sj ∈ Aj , where t∈ TA. The subFSM MB = (B, B0, TB , δB ) corresponding to the partition B can be similarly defined. Consider the FSM shown in Figure3-28. In this example, S = {S1, S2, S3, S4, S5, S6} is a set of states. Two partitions satisfying the constraint are A = {{S1, S2, S3}, {S4, S5, S6}} and B = {{S1, S6}, {S2, S5}, {S3, S4}}. Here A1 = {S1, S2, S3}, A2 = {S4, S5, S6}; and B1 = {S1, S6}, B2 = {S2, S5}, B3 = {S3, S4}. [15, 16] It is easy to check that transition t1 occurs on all the states of A1 and it maps A1 into A2, all other transitions {t3, t4, t5} of M map A1 into A1. Similarly transition t2 occurs on all the states of A2 and maps A2 into A1 and other transitions {t1, t3, t4, t5} map A2 into A2. Thus the corresponding subFSM MA has transitions TA = {t1, t2}, because t1 occurs on all states of A1 and t2 occurs on all states of A2. The next state function δA is computed as follows [11]: δA(A1, t1) = A2 since δ(S1, t1) = S6, δ(S2, t1) = S4, δ(S3, t1) = S4, and (S6, S4, S4) ∈ A2, similarly δA(A2, t2) = A1. The subFSM MB has transitions TB = {t1, t3, t4, t5} and δB is written as follows: δB (B1, t4) = B3, δB (B3, t3) = B2, δB (B2, t1) = B3, δB (B2, t5) = B1. The subFSMs MA and MB as part of the AND state are shown in Figure 3-44. [pic] Figure 3-44: subFSMs of an AND State 3.6.4 A Statechart Extraction Methodology [pic] Figure 3-45: implementation design of extraction method We have named our method to extract statechart representation from FSM, Our method to extract an equivalent statechart from FSM is based on first introducing hierarchy in the given FSM. After that we apply the decomposition method discussed in last section. This introduces concurrency in the FSM. Figure 3-45 illustrates the implementation of the class design for the extraction methodology. We introduce hierarchy into a given FSM by determining commonality of transitions. That is, an OR state can be formed when an FSM has at least two states onto which the incident transitions have the same label. When forming an OR state, all such transitions are replaced with a single, similarly labeled leaving transition of the OR state. An example to illustrate this approach is shown in Figure 3-46. In the figure 4(a) states A and B have a similarly labeled transition t leading to state C . Thus the states A and B can become part of the OR state (Z ) and the two t transition can be replaced by a single transition t from the OR state leading to state C . [22] [pic] Figure 3-46: Formation of an OR State Now, we illustrate our extraction method using a more complex example shown in Figure 3-47. The example FSM has seven states and the state S1 is the initial state. We introduce hierarchy into the FSM by considering the common transitions f and y coming out from the states (S1, S2) and (S3, S4, S5, S6) respectively. The resulting hierarchical FSM with OR states A and K, is shown in Figure 3-48. Now we apply the decomposition concept discussed in the last section to introduce the concurrency in the FSM of OR state K. We get two subFSMs MA and MB having states {{S3, S4}, {S5, S6}} and {{S3, S5}, {S4, S6}} respectively. These states have been shown inside the state K in Figure 3-49. The statechart extracted from FSM, after introducing hierarchy and concurrency is shown in Figure 3-49. The statechart extracted from FSM, after introducing hierarchy and concurrency is shown in Figure 3-49. [pic] Figure 3-47: An Example FSM for the extraction methodology [pic] Figure 3-48: Hierarchical FSM [pic] Figure 3-49: Statechart for the Example of the FSM 3.6.5 The implementation of the Theorem Method This method to extract statecharts from FSMs is behavior preserving, we will prove this in the following section. Subsequently, we also show that the extraction methodology may yield different statecharts for the same FSM depending on the order in which the hierarchy and concurrency are selected. Figure 3-50 depicts the implementation of class design of the theorem method of this module. [pic] Figure 3-50: the implementation design of Theorem Mthod Theorem Mthod 1 The statechart yielded by extraction methodology preserves the state behavior of the original FSM. Proof: This can be proved as follows. If we flatten the statechart S by using the approach reported in[12], we get the flattened statechart (i.e. an FSM M’ ). And by the Bisimilarity technique of [17] for matching diagrams, it could be proved that M and M’ are equivalent. Therefore, first we build the cross product of state sets of all the and components and transitions are considered next. It is important to note when considering the transitions, that if an event can not be consumed by a fired transition then statechart drops that event. So, an AND state can contain many statecharts, and which is active and which is not, it may be possible that some events may be consumed and some may not (dropped). Following this we can define the transitions that have to be created: Suppose (S1, · · ·, Sn) is a state obtained from the cross product. If this state is active and an event e occurs, then there may be some statecharts which consume e by a transition Si → ti and some drops it and stay in their state Si = ti. Therefore, the OR state resulting from the AND state must contain a transition (S1,…Sn)→(t1,…tn). [pic] Figure 3-51: Flattened statechart Removing an OR state is simple. If an OR state is active then any one of the contained substate is active, so we can remove the OR state frame but must take care of the transitions leading to and leaving from the OR state. All the transitions leading to OR state are redirected to OR state’s intial pseudo state and an OR state can always be left by a transition from the OR state, so each such transition has to be replaced by copies from each of the contained states, is flattened by the above described approach. Flattened statechart is presented in Figure 3-51. Theorem Method 2 the methodology can yield different staehcart of an FSM depending on the order of selection of hierarchy and concurrency. Proof: We can prove this through contradiction. Assume that the same statechart is constructed irrespective of the order in which hierarchy and concurrency are slected. Now we negate this by constructing a counter example. An example presented in Figure 3-52(a) [40] which results in two different statecharts (semantically equivalent) by the extraction methodology, shown in Figure 3-53 and Figure 3-54 respectively. Figure 3-53 shows the statechart obtained by first applying concurrency and then hierarchy, whereas Figure 3-54 [39] shows a statehchart obtained by applying concurrency and hierarchy in reverse oreder. [pic] Figure 3-52: FSMs for Decomposition As a corollary of Theorem Method 2, it is possible to construct several equivalent statecharts through application of the extraction methodology. It is therefore necessary to compare the “goodness” of extracted statecharts, so that the most suitable one can be chosen. Genero at. al [16] proposed a metric to measure structural complexity of statecharts. [pic] Figure 3-53: Equivalent Statechart 1 for the Example in Figure 3-52(a) [pic] Figure 3-54: Equivalent Statechart 2 for the Example in Figure 3-52(a) 3.6.6 Conclusion of this section We have proposed a method to transform an FSM to its equivalent statechart. This transformation method first introduces hierarchy and then concurrency in the FSM. Hierarchy is introduced considering the concept of common transitions and concurrency is based on the concept of decomposition. We have also given an example to illustrate the proposed technique. We have proved that our proposed transformation technique preserves the behavior and also showed that the technique may result in different statecharts of an FSM but semantically equivalent. Their complexity is also measured so that the statechart with the lower value can be chosen. Sometimes our proposed technique may fail i.e. resulting statechart is the same as the original FSM. Hence to deal with such cases an arbitrary FSM decomposition method is presented. 3.7 Key techniques Difficult points and key techniques ➢ The approach to extract event trace and sequence diagram or scenarios from the legacy system ➢ The methodology and algorithm to editor the event trace which gained from call tree of the Jprofiler to the proper scenarios ➢ The improvement of the BK-algorithm and modify it to the adapted BK-algorithm ➢ Implementation of the synthesis of the state machine from scenarios through the adapted BK-algorithm. ➢ The methodology and algorithm to extract statechart from the representation FSMs. ➢ The implementation of the prototype tool, it needs conduct the theory to the realistic visualized application. 3.8 Brief summary In this chapter we mainly demonstrate the methodology and algorithm of each process and transition of the diagrams and models. we take an experimental legacy ATM machine which we simply developed to represent the enterprise target system. After the applying of the program tracer Jprofiler, we mainly required the call tree ofor the target system, combining the methodology we construct to editor the event trace to the sequence diagram or scenarios of the target system. A novel approach based on the BK-algorithm is proposed to implement the synthesis of the state machine from scenarios of the legacy system. After obtaining the state machine of the system, it is still FSM, since FSMs can be difficult to understand and use. We have proposed a methodology preserving extraction of a statechart from an FSM. Chapter 4 Implementation of prototype tool and Testing 4.1 The environment of prototype implementation This section wil demonstrates the environment we used to implement the prototype tool. Hardware facilities: Laboratory, PC, Documents Software: MyEclipse with associated plugins, Jprofiler, Windows system Programming language: JAVA, XML, XSL 4.2 Implementation of the synthesis of state machine prototype 4.2.1 Implementation of input scenarios As the program tracer execution for the scenarios, we could draw the scenario diagram in the associated plugin of the platform; it can transfer the diagram to the XML structure to store the diagram. We add the scenarios as the input of the generation state machine module. The implementation interface as shown in the Figure 4-2. And also the figure 4-1 illustrates the XML structure which represent the Scenario withdraw option. [pic] Figure 4-1: XML structure of the scenario diagram [pic] Figure 4-2 Interface of adding the scenario in XML structure [pic] Figure 4-3: Interface of adding scenario 1 We need to input all the scenarios to generate the state machine. Figure 4-3 shows the input of the withdraw_Scenario and the diagram generated by the associated plugin in the developed platform. It is recorded as the Scenario 1 in the tools. [pic] Figure 4-4：Interface of adding scenario 2 As figure 4-4 shows the Deposit_Scenario is added into the system as the scenario 2. [pic] Figure 4-5: Interface of adding scenario 3 For the Transfer_Scenario, the figure 4-5 shows it is the input for the generation of the state machine. It is added as the scenario 3 in the tool. After then, the input of the scenarios is already finished. We could use the scenarios which been added to generate the state machine. 4.2.2 Implementation of Generating State Machine Figure 4-6 shows the prototype we developed the prototype of synthesis of the state machine according to the adapted BK-algorithm, and as the input is the scenarios generated from the experimental legacy system. [pic] Figure 4-6: Prototype of synthesized state machine Figure 4-6 shows the interface of the generation of the State machine, as we store the scenarios, we also use the plugin of the platform to record the state machine in XML structure, as figure 4-8 we could see that the stathe machine is exported into the XML file. As the Figure 4-7 depicts the XML structure of the obtained state machine diagram. [pic] Figure 4-7: XML Structure of the obtained state machine diagram [pic] Figure 4-8: Interface of input state machine of XML structure We get the scenarios from the legacy system through the editor scenario methodology. Although maybe the obtained scenarios are not extremely accurate, it could almost represent the action flow through the entire process. Then we manually combine the scenarios by applying the algorithm which implemented in the prototype tool to generate the state machine of the experimental system as in Figure 4-1. 4.2.3 Implementation of statechart of the experimental system From the last section, we could see in Figure 4-9，it is the generate statechart chart module. First we need to input the state machine which stored in XML structure, the interface is as Figure 4-9. The drawn FSM is exported to XML Structure via File→ Export→ XML command. Various classes and their attributes are shown below to give some idea of implementation. [pic] DataR class represents the each cell of the row of state transition table of hierarchical FSM that contains the information of transition to next state. DataC class represents the each cell of the column of state transition table. Each cell has First and Second as pointer, pointing to state transition tables of subFSMs. Each state in hierarchical FSM can be either a plain state or composite state. state is the current state of state machine. Next pointer points to next state on transition occurrence. [pic] Each state transition table of hierarchical FSM is passed to AND StateHandler for deocomposition. If it succeeds then decomposes into two subFSMs. The state transition tables for these subFSMs are represented by the classes given below. Column class gives the information of each cell containing state state and next pointer to next state. Row class gives the information of each cell of the row of state transition table containing next state and transition information. [pic] [pic] As we already discussed in section 3.4, the methodology to synthesis the FSM. After the XML file is selected for transformation, tool transforms it into an intermediate representation (here state transition table) for manipulation. Then tool finds the OR and AND states, that can be formed and transform the input FSM into a hierarchical state transition table representing FSM after composition. The interface of generation statechart is shown in Figure 4-9. [pic] Figure 4-9: Interface of the output Generated statechart 4.3 The prototype tool Testing 4.3.1 Testing plan Testing plan is consisted with each revelant phases, in the phase of requirements analysis, we will make the acceptance testing plan, in the design phase, the system testing plan is proceeded, in detailed design phases when we excute the detailed design, we make integration testing plan, also in the program unit design phase the unit testing plan will be carried out, this is demonstrated as figure 4-10. As the figure shows, we could see that the left part of the graph is the process of design and implementation, while at the same time we prepare each testing plans, when the coding phase is accompanied, we could excute the testing tasks. [41] [pic] Figure 4-10: Testing plan in software development life cycle 4.3.2 Test Cases and results The program tracer testing For the program tracer testing, as we discuss in the chapter 3, we choose the Jprofiler as the program tracer to parse the legacy system. Therefore, we take the experimental example system ATM machine system as the Experimental Testing case for the program tracer test. As we can see from the following graph Figure 4-11, the tracer Jprofiler parses the withdraw option with showing a call tree correctly represent the relationship of the different objects in the ATM system under the withdraw option. And each method invokes another one is shown in the structure of the results precisely. Consequently, the execution of the program tracer is creditable of the statistic it parses from the original system. [pic] Figure 4-11: Execution result of the program tracer The generation of state machine Testing For testing the function of the generation of state machine, we take another simple experimental example that is traffic light systems which only have two scenarios. The event trace could be given as follows: [pic] The execution result of the example is as the figure 4-12 shows. [pic] Figure 4-12：the result of the generation of state machine test case We can see from the result the state machine generated is mostly corresponding to the scenarios of the traffic lights system except the transition message. The transition message from the “NS straight” to the state “NS turn left” is missing in this stat machine. In future work, the problem will be solved through the more improved approach. The Testing for converting FSMs to statecharts As we can see from the chapter 3, the module for the generation statechart from FSM related to the improvement in structural complexities. We have applied the prototype tool on a large number of randomly generated various FSM models. We present a general experiment here to analysis and verify the approach and theory proposed in chapter 3. The input FSM considered for this and the statechart obtained after transformation is shown in Figure 4-13. [pic] Figure 4-13: Obtained Statechart from FSM of Figure 4-1 Results are summarized in Table 4-1. Each entry in the table shows the values that are an average of ten experiments. We found from experimentation with FSMs of different sizes that the average complexity improvement [24, 27] is 27.68%. The variations in improvement from FSM of one size to another may be because different FSMs may result in different statecharts having different number of composite states (OR/ AND). Also, the FSMs with the same number of states and transitions can result in statecharts having different structures as per Theorem 2 (chapter 3), so their complexities also differ. Table 4-1: Comparision of Structural Complexities |State |Transitions |FSM |Statechart |%Improvement | | | |SC Metrics |SC Metrics | | |6 |14 |20 |14 |30.00 | |7 |17 |24 |19 |20.83 | |9 |18 |27 |22 |18.51 | |15 |33 |48 |37 |22.91 | |24 |54 |75 |46 |41.02 | |37 |58 |95 |73 |23.15 | |45 |97 |142 |83 |41.54 | |63 |87 |150 |113 |24.67 | |97 |126 |223 |183 |17.93 | |117 |153 |270 |172 |36.29 | Conclusion We have shown that automatic or mostly automatic state machine synthesis is a realistic possibility that should be taken into account in the design of future OO software design environments. The application of this approach implies hat the emphasis in the construction of the dynamic model is laid on the scenarios rather than on state machines. The latter can be considered, at least partially, as a mechanical summary of the former. As to the enterprise interoperability federated approach proposed by PHD Tu Zhiying’s research proposing a development lifecycle that is tending to reuse existing information systems without recoding them but by adapting them to the new requirements of interoperability dynamics. Consequently the enterprise business behavior interface should be implemented to abstract the dynamic description of the enterprise. Our method supports this view, providing automatic means to derive the dynamic model automatically from a set of scenarios. In this dissertation and also in my research, we take an experimental legacy ATM machine which we simply developed to represent the enterprise target system. After the applying of the program tracer Jprofiler, we mainly required the call tree ofor the target system, combining the methodology we construct to editor the event trace to the sequence diagram or scenarios of the target system. A novel approach based on the BK-algorithm is proposed to implement the synthesis of the state machine from scenarios of the legacy system. In the methodology of synthesizing state machine diagrams from scenarios, we propose appropriate steps and rules for the generation of the state machines from multiple scenarios, according to the initial scenarios. Our approach provides complete requirements specifications of the project, an accurate design, and the implementation. [16] A prototype tool of this approach has been implemented in Java. After obtaining the state machine of the system, it is still FSM, since FSMs can be difficult to understand and use. We have proposed a methodology preserving extraction of a statechart from an FSM. Our method can be applied to not only FSMs of objects but FSMs used in other modeling applications. We first identify and introduce hierarchy and then introduce concurrency. Our decomposition algorithm is based on finding two or more subFSMs of an FSM. And also a prototype of this algorithm has been implemented in Java. By the three key process and phases of appropriate methodology and algorithm, we implement the extraction and abstraction of the dynamic model from the static model and legacy system. Finally we get the statechart to represent the dynamic behavior of the experimental system in order to describe the business process of the enterprise. References [1] Zhiying Tu, Gregory Zacharewicz, David Chen: Harmonized and Reversible development framework for HLA based interoperable application, 2011. [2] Zhiying Tu, Gregory Zacharewicz, David Chen: A Federated Approach to develop Enterprise Interoperability, 2012. [3] TARJA SYSTÄ and PING Yu, Using OO Metrics and Rigi to Evaluate Java Software, Canada, 10-25 1999. [4]Mirror of Wikipedia Reverse engineering,http://en.wikilib.com/Wiki/reverse-engineering, 1999 [5] MDA FAQ, http://www.omg.org/mda/faq_mda.htm, 2009. [6] Demeyer S., Ducasse S., and Lanza M., A Hybrid Reverse Engineering Approach Combining Metrics and Program Visualization, In Proc. of the 6th Working Conference on Reverse Engineering, IEEE Computer Society Press, 1999, pp.175–186. [7] Harel D. and Politi M., Modeling Reactive Systems with Statecharts: The STATEMATE Approach, McGraw-Hill, 1998. [8] Jean Bezivin (A) Mickael Barbero (CO) Frédéric Jouault (CO), On the Applicability Scope of Model Driven Engineering, ATLAS Group, Nantes Univ. 2007 [9] Leue S., Mehrmann L., and Rezai M., Synthesizing Software Architecture Descriptions from Mes- sage Sequence Chart Specification, In Proc. of the 13th IEEE International Conference on Automated Software Engineering (ASE98), IEEE Computer Society Press, 1998, pp. 192–195. [10] Wikipedia. Devs—wikipedia, the free encyclopedia,2009.URL http://en.wikipedia.org/w/index.php'title=DEVS&oldid=279731933.[Online;accessed 2-March-2009]. [11] Ma¨nnisto¨ T., Systa¨ T., and Tuomi J., Synthesizing OMT State Diagrams, In Proc. of the 4th Symposium on Programming Languages and Software Tools, Dept. of Computer Science, Eo¨ tvo¨ s Lo´ rand University of Budapest, 1995, pp. 21–32. [12] ADM Task Force: Architecture Driven Modernization Roadmap. OMG.adm.omg.org(2007) [13] Henderson-Sellers B., Object-Oriented Metrics, Measures of Complexity, Prentice Hall, 1995. [14] Bernard P. Zeigler and Hessam S. Sarjoughian. Introduction to devs mod-eling and simulation with java: Developing component-based simulation models, 2005.URL http://www.acims.arizona.edu/SOFTWARE/devsjava_ licensed/DevsJavaUserGuidev1.1.zip. [15] Favre, L.: Foundations for MDA-based Forward Engineering. Journal of Object Technology (JOT) 4(1), 129–153 (2005) [16] Simona VASILACHE and Jiro TANAKA Synthesis of State Machines from Multiple Interrelated Scenarios Using Dependency Diagrams, JAPAN, 2005 [17] Koskimies K., Mäkinen E.: Automatic Synthesis of State Machines from Trace Diagrams. Software Practice & Experience 24,7 (July 1994),643-658. [18] Harel D. and Politi M., Modeling Reactive Systems with Statecharts: The STATEMATE Approach, McGraw-Hill, 1998. [19] Chase M., Christey S., Harris D., and Yeh A., Managing Recovered Function and Structure of Legacy Software Components, In Proc. of the 5th Working Conference on Reverse Engineering (WCRE98), IEEE Computer Society Press, 1998, pp. 79–88. [20] Coleman D., Hayes F., and Bear S., Introducing Objectcharts or How to Use Statecharts in Object- Oriented Design, IEEE Trans. Softw. Eng., 18, 1, January 1992, pp. 9–18. [21] Ashish Kumar: A Novel Technique to Extract Statechart Representation of FSMs. M Tech Thesis, Deptt. of Computer Science and Engineering, IIT Kharagpur, 2008. [22] Chen D., Doumeingts G., Vernadat F. Architectures for Enterprise Integrationand Interoperability: Past, Present and Future. In: Special issue on EnterpriseIntegration and Interoperability in Manufacturing Systems, A. Molina and H.Panetto (Eds). Computers In Industry, 59/5, May 2008, Elsevier. [23] Panetto H. Towards a Classification Framework for Interoperability of Enterprise Applications. International Journal of CIM, 20/8, 727-740, Taylor & Francis, December 2007, ISSN 0951-1 [24] Gamma E., Helm R., Johnson R., and Vlissides J., Design Patterns: Elements of Object-Oriented Software Architecture, Addison-Wesley, 1995. [25] IBM Research, Jinsight, visualizing the execution of java programs, http://www.research. ibm.com/jinsight/, 2000. [26] Favre, L.: Foundations for MDA-based Forward Engineering. Journal of Object Technolorgy (JOT) 4(1), 129–153 (2005) [27] Koskimies K. and Ma¨kinen E., Automatic Synthesis of State Machines from Trace Diagrams, Softw.Pract. & Exper., 24, 7, 1994, pp. 643–658. [28] Li W. and Henry S., Maintenance Metrics for the Object Oriented Paradigm, In Proc. of the 1st Intl. Software Metrics Symposium, IEEE Computer Society Press, 1993, pp. 52-60. [29] Biermann A.W., Baum, R.I., and Petry, F.E., Speeding up the Synthesis of Programs from Traces, IEEE Trans. on Computers, 24, 2, 1975, pp. 122–136. [30] Tewfik Ziadi and Yan-Gael Gueheneuc, Automated Reverse-engineering of UML v2.0 Dynamic Models, 1-3, 2003. [31] Hsia P., Samuel J., Gao J., Kung D., Toyoshima Y., and Chen C., Formal Approach to Scenario Analysis, IEEE Software, 11, 2, March 1994, pp. 33–41. [32] Innovative Software GmbH, Innovative Software Homepage, http://www.innovative- software.co.uk/oew/index.html, 1999. [33] Graham I.M., Migrating to Object Technology, Addison-Wesley, 1995 [34] Harel D., Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming, 8, 1987, pp. 231–274. [35] Z.120 ITU-T Recommendation Z.120: Message Sequence Chart (MSC), ITU-T, Geneva, 1996. [36] Jacobson I., Object-Oriented Software Engineering — A Use Case Driven Approach. Addison-Wesley, 1992. [37] Jerding D. and Rugaber S., Using Visualization for Architectural Localization and Extraction, In Proc. of the 4th Working Conference on Reverse Engineering (WCRE97), IEEE Computer Society Press, 1997, pp. 56–65. [38] Kazman R. and Carriere J., Playing Detective: Reconstructing Software Architecture from Available Evidence, Automated Software Engineering, 6, 2, 1999, pp. 107–138. [39] Harel D., Lachover, H., Naamad, A., Pnueli, A., Politi, M., Sherman, R., Shtull-Tauring, A., and Trakhtenbrot, M., STATEMATE: A Working Environment for the Development of Complex Reactive Systems, IEEE Trans. Softw. Eng., 16, 4, 1990, pp. 403–414. [40] Khriss I., Elkoutbi M., and Keller R., Automating the Synthesis of UML Statechart Diagrams from Multiple Collaboration Diagrams, In Bezivin J. and Alain P. (eds.), The Unified Modeling Language. UML’98: Beyond the Notation, Springer-Verlag, LNSC 1618, 1999, pp. 132-147. [41] IntegriSoft Inc., IntegriSoft Homepage, http://www.integrisoft.com/, 1999 Acknowledgement Evaluations of supervisors |Evaluation of Supervisor at Industry： | |[pic] | | | | | | | | | | | | | |Supervisor (sign)： | |Evaluation of Supervisor at Partner University： | | | |[pic] | | | | | | | | | | | | | | | | | |Supervisor (sign)： | |Evaluation of Supervisor at Harbin Institute of Technology： | | | | | | | | | |Supervisor (sign)： | |Evaluation about the proposal of the exam team: | | | | | | | | | | | |(sign)： Y M D | ----------------------- UNIVERSITE BORDEAUX 1 Method call count before applying the rules