MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345 PRISM model checker as an Eclipse-plugin DIPLOMA THESIS Bc. Milan Malota Brno, Autumn 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. In Brno, January 11, 2016 Bc. Milan Malota Advisor: RNDr. Vojtechˇ Rehˇ ak,´ Ph.D. ii Acknowledgement I would like to thank my advisor Vojtechˇ Rehˇ ak´ for valuable advice, com- ments, support and patience during the writing of this thesis. I also want to express my gratitude to my family and my girlfriend for their support during studies. iii Abstract PRISM is a probabilistic model checker and is used in many different ap- plication domains and is well known among scientists dealing with formal modeling and analysis of systems that exhibit random or probabilistic be- havior. PRISM’s GUI was developed in the beginning of the PRISM life cycle and technologies made great progress so it can seem obsolete. That is why the request for a new GUI was pronounced. One of the platforms suitable for integrating an application and preferred by the original development team is the Eclipse platform. In the scope of this thesis we analyze available Eclipse platforms and notable graphical user interface frameworks. On the basis of the analysis new graphical user interface allowing all funcionality of the current PRISM GUI is implemented. iv Keywords PRISM, Eclipse RCP, Eclipse e4, AWT, Swing, SWT, JFace, Albireo v Contents 1 Introduction ...... 3 1.1 Motivation ...... 3 2 Preliminaries ...... 5 2.1 PRISM model checker ...... 5 2.1.1 The PRISM language ...... 5 2.1.2 Properties ...... 6 2.1.3 Experiments ...... 7 2.1.4 Simulations ...... 7 2.2 The PRISM’s graphical user interface (GUI) ...... 7 2.3 The model editor ...... 8 2.4 The properties editor ...... 9 2.5 The simulator environment and log ...... 9 2.6 GUI conclusion ...... 10 3 The Eclipse Rich Client Platform ...... 11 3.1 Eclipse ...... 11 3.2 The Eclipse RCP ...... 11 3.2.1 The OSGi framework ...... 12 3.2.2 The SWT framework ...... 13 3.2.3 JFace ...... 13 3.2.4 Other Eclipse APIs ...... 13 3.3 The Eclipse 3.x platform ...... 13 3.4 The Eclipse e4 platform ...... 14 3.5 Eclipse Public License ...... 14 3.6 The Eclipse RCP conclusion ...... 14 4 The frameworks selection ...... 16 4.1 The Eclipse RCP platform selection ...... 16 4.1.1 The framework ...... 16 4.1.2 Dependency injection ...... 17 4.1.3 The dynamic application model ...... 17 4.1.4 GUI independence ...... 17 4.2 The user interface framework selection ...... 17 4.2.1 Abstract Window Toolkit (AWT) ...... 18 1 4.2.2 The Swing framework ...... 19 4.2.3 The Standard Widget Toolkit (SWT) ...... 19 4.2.4 JFace and SWT ...... 19 4.2.5 The user interface frameworks conclusion ...... 20 5 Implementation of the PRISM Eclipse plugin ...... 22 5.1 IDE and installation of e4 tools ...... 22 5.2 New project creation ...... 22 5.3 Application model ...... 23 5.4 Annotations ...... 25 5.5 GUI elements implementation ...... 26 5.5.1 SWT and JFace ...... 26 5.5.2 Swing ...... 27 5.6 Swing components integration ...... 28 5.6.1 Multiple Event Threads ...... 28 5.6.2 Look and feel ...... 29 5.6.3 Application Flickering ...... 29 5.6.4 Modal dialogs ...... 29 5.6.5 Pop-up menus dismissing ...... 30 5.6.6 Keystroke logging ...... 30 5.6.7 Albireo project ...... 30 5.7 Eclipse plugin packages ...... 31 5.8 Plugin core classes ...... 32 5.9 Cascading style sheets (CSS) ...... 33 5.10 Exporting and platform independency ...... 33 5.11 The Eclipse PRISM plugin conclusion ...... 34 6 Future work ...... 36 6.1 Building via Maven ...... 36 6.2 Continuous integration to SWT ...... 36 7 Conclusion ...... 37 8 Source code information ...... 38 2 Chapter 1 Introduction In a life cycle of a computer program we can find in the first position an idea for a program. In some cases the idea is pretty clear and there are no doubts, on the other hand in some cases the idea is slightly blurred. A difference is often in a motivation. Developers often does not know if their application is capable of addressing a potential user and if time invested in developing brings rewards or not. 1.1 Motivation The main goal of this thesis is to create a new graphical user interface (GUI) for an existing application called PRISM. PRISM is a probabilistic model checker and is used in many different application domains and is well known among scientists dealing with formal modeling and analysis of systems that exhibit random or probabilistic behavior [21]. The detailed information about PRISM is provided in the Section 2.1. PRISM is implemented as a standalone application, so a question why is a new GUI needed can come to the surface. The answer to the question is simple. The GUI was developed in the beginning of the PRISM life cycle and technologies made great progress so it can seem obsolete. One of the platforms suitable for integrating an application and pre- ferred by the original development team is the Eclipse platform. The Eclipse platform defines a set of frameworks and common services that allow devel- opers to create a rich client platform (RCP), we deal with RCP in Chapter 3 in detail. In Chapter 4 we describe notable Eclipse platforms and graphical user interface frameworks. We compare their advantages and disadvantages and on the basis of the comparison and test development of the possible approaches we select the most suitable Eclipse platform and GUI framework in which a new GUI for the PRISM model checker should be implemented. Further in Chapter 5 we describe issues we had to face during the de- 3 1. INTRODUCTION velopment of the selected approach; we also provide solutions for these issues. Finally in Chapter 6 we provide a list of suggestions for future work as the approach selected in the scope of this thesis usually presents transition point toward new implementation. 4 Chapter 2 Preliminaries In this chapter we provide basic information about the PRISM language and the PRISM model checker. 2.1 PRISM model checker PRISM is a probabilistic model checker. The latest version (4.2.1) provides support for formal modelling and analysis of systems that exhibit random or probabilistic behavior [21]. PRISM is used to analyse a wide range of case studies in many different application domains, including randomised distributed algorithms, communication, network and multimedia protocols, security, biology, planning and synthesis, game theory, performance and reliability, power management and CTMC benchmarks [34]. For more about case studies see [1]. 2.1.1 The PRISM language In order to understand PRISM works we have to introduce the PRISM lan- guage, a simple, state-based language. This is used for all types of model that PRISM supports: discrete-time Markov chains (DTMCs), continuous-time Markov chains (CTMCs), Markov decision processes (MDPs) and probabilis- tic automata (PAs), probabilistic timed automata (PTAs). [21] Every PRISM model comprises a set of modules which represent different components of the system being modelled. For representation of the state of each module a set of variables is introduced. In Figure 2.1 we can see an example of the PRISM modelling language. The example shows a simple case study based on a single cell in a wireless communication network. In order to specify additional measures of interest of modelled systems rewards can be utilized. The way of rewards specification is in our example in Figure 2.1. Rewards typically represent the rate at which a reward is accu- mulated, rewards usually represent an instantaneous measure of interest, at a 5 2. PRELIMINARIES // single cell in wireless communication network // gxn/dxp 5/3/01 ctmc const i n t N; // N − number of channels const double lambda1=49; // arrival rate of new calls const double lambda2=21; // arrival rate of hand−o f f c a l l s const double mu=1; // departure rate of calls module c e l l n : [0..N]; // number of calls in the cell // arrival of new call [ ] ( n // number calls in the cell rewards ” c a l l s ” true : n ; endrewards Figure 2.1: A case study based on a single cell in a wireless communication network [37] particular time, in our case, number of calls in the cell. For more information about the semantic of the PRISM modelling language, see the manual [35]. 2.1.2 Properties We have discussed basic information about the PRISM modelling language, when we have a model, we have to specify one or more properties. Properties are based on temporal logic, which offers a flexible and unambiguous means of describing a wide range of properties. In order to specify properties of DTMCc, MDPs or PTAs PCTL is used; CSL is an extension of PCTL for CTMCs; LTL and PCTL* can be used to specify properties of DTMCs and MDPs (or untimed properties of CTMCs) [36]. 6 2. PRELIMINARIES const double T; // time bound // the maximum probability that a hand off call can be // dropped within t time units (assuming a guarded channel is free) P=?[ true U<=T ( n=N) {n // the expected number of calls at time T R{” c a l l s ”}=? [ I=T ] // the probability that in the long run any call can be dropped S=? [ n // the expected number calls in the cell in the long run R{” c a l l s ”}=? [ S ] Figure 2.2: A definition of properties [37] In Figure 2.2 we offer an example of the properties specification. The purpose of each property can be understood from comments labelling the example. Model and properties specifications together create platform for modelling most systems. 2.1.3 Experiments In some cases of system analysis it is more telling to generate and plot a range of studied values. Then, in the scope of the PRISM model checker we speak of experiments. Experiments are ways of automating model checking. The best usability is reached when we study trends in quantitative results. The results of experiments can be visualized via integrated graph plotting tool. 2.1.4 Simulations PRISM includes a simulator, a toll which can be used to generate sample paths through a PRISM model. This is useful for debugging models during development and for running sanity checks on completed models. For more about simulations see [33]. 2.2 The PRISM’s graphical user interface (GUI) Because a new GUI should be implemented in the scope of this thesis we have to analyse the existing one. We have already mentioned that the PRISM 7 2. PRELIMINARIES is implemented as a standalone application. All of the functionality of PRISM is available from a command-line as well. The command-line PRISM is more suitable for executing large batches of model checking runs or for combining PRISM with other tools through scripting [20]. The graphical PRISM provides: • a model editor for the PRISM modelling language with syntax high- lighting and error reporting, • a properties editor, • a simulator tool for exploring and debugging PRISM models • a simple log output window, • graph-plotting tools. On top of main PRISM window there is a menu. The menu is divided in accordance to available PRISM features. The most important menu items are Model, Properties and Simulator. The Model menu contains basic features for work with a textual model, it allows to open, reload or save a model from or to an existing file. Moreover, it allows to parse, build or export the model. The Properties menu enables work with properties (see 2.1.2). Finally, the Simulator menu allows to simulate required behavior in a modelled system. Below the main menu there is another menu. This menu consists of standard text editor icons and facilitates work with textual elements in GUI (e.g. undo, redo, copy, paste etc.). 2.3 The model editor The model editor (see Figure 2.3) is the core of the PRISM graphical user interface. It consists of two elements: model explorer and text editor. The model explorer provides comprehensive information about a mod- elled system. It describes model in the compact way i.e. list of modules, variables and constants. It also indicates whether there is a syntax error in model or not. We have already mentioned that every model has to be first described in textual representation. The PRISM’s text editor allows editing of such models. It also provides syntax highlighting and syntax checking on the fly. The editor is implemented as well as the rest of GUI in the Swing framework, more about Swing is discussed in Section 4.2.2. 8 2. PRELIMINARIES Figure 2.3: Screenshot of the PRISM text editor 2.4 The properties editor In the scope of this chapter we introduced properties. For editing properties there is next component of the PRISM graphical user interface (see Figure 2.2). Properties can be also load from an external file. On the left side of the properties editor we can see three tables for prop- erties, constants and labels. On the right side of the properties editor there is an environment for experiments (see 2.1.3). The results of experiments are often plotted in a set of graphs that are a very useful way of identifying interesting patterns or trends in the behavior of a modelled system. 2.5 The simulator environment and log Next to the model editor and properties editor there are other two main windows in PRISM: Simulator and Log. Simulator is an environment that allows, in a very intuitive way, to explore a model in order to debug model during development or to sanity check on completed models. For more about debugging model with the simulator see [33]. The log is the last of the PRISM main GUI elements. It is implemented 9 2. PRELIMINARIES Figure 2.4: Screenshot of the PRISM property editor and experi- ment environment as a text area that cannot be edited. In log window users can find basic information about model checking procedures, computations, results or states. 2.6 GUI conclusion PRISM has a simple GUI. It consists of two menus and four main parts, each for one of the main types of functionality offered by PRISM. The appearance of the GUI corresponds with the look and feel of Swing components. The biggest disadvantage can be found in the impossibility of advanced customizing of user interface (e.g. layout of PRISM’s elements cannot be modified), on the other hand the PRISM’s GUI has long tradition and is designed and implemented by people that work with PRISM for a long time. 10 Chapter 3 The Eclipse Rich Client Platform In this chapter we introduce the Eclipse Rich Client Platform (RCP). RCP is considered as the basis of applications in industries worldwide including finance, transportation, space exploration, environmental monitoring or manufacturing. In [12] you can see an exemplary list of application built on the RCP core. 3.1 Eclipse In this chapter we deal with the Eclipse RCP. Before we get to the detailed analysis of RCP we would like to say few words about Eclipse. Eclipse is and open-source community of people building Java-based tools and infras- tructure to help developers solve problems. The most obvious output of the community is the Eclipse Java Integrated Development Environment (IDE). This world-class Java IDE usually tops the charts in developer satisfaction and use. [24] Underneath the IDE is a generic tooling platform that supports a wide range of tools for languages (see [11] for list of supported programming languages) and systems. The Eclipse component model means that these tools can be combined and integrated as needed. 3.2 The Eclipse RCP Under the tooling platform is the Eclipse RCP. This is a generic platform for running applications. The Eclipse IDE happens to be one such application. RCP is commonly thought as a UI framework. Many development teams adopt RCP because it accelerates the development and deployment of desktop and embedded client-side applications. However, the RCP can be thought much more than that. RCP is not a single framework but a collection of lower-lever frameworks. If we want to understand the way the RCP works we must introduce these 11 3. THE ECLIPSE RICH CLIENT PLATFORM framework: • The Open Service Gateway Initiative (OSGi) – at the lowest level, all RCP applications run on top of an OSGi framework [2] • The Standard Widget Toolkit (SWT) - open source widget toolkit for Java application to provide the primitive widgets (e.g. radio buttons, text controls, scroll bars, etc.) [14] • JFace – user interface toolkit with classes for handling many common UI programming tasks, designed to work with SWT without hiding it [10] • other Eclipse APIs – not strictly part of RCP itself 3.2.1 The OSGi framework The OSGi standards define the OSGi framework specification. The OSGi framework provides a modularity and component layer on top of standard Java platform. Modules in OSGi are packaged as bundles. [23] An OSGi application is a collection of one or more bundles executing in an OSGi framework. The framework takes care of all the dependency resolution, class loading, service registration, and event management. The framework is reified in a running system as the System Bundle. Rep- resenting the OSGi framework as a bundle allows us to view the entire platform consistently as a collection of collaborating bundles. While the System Bundle is clearly special, it contains manifest, exports packages, provides and consumes services, and broadcasts and listens to events like any other bundle [25]. The System Bundle differs from other bundles in that its lifecycle cannot be managed. It is started automatically when the framework is started and continues in the active state until the framework is stopped. Stopping the System Bundle causes the framework to shut down. Similarly, the System Bundle cannot be uninstalled while running, since doing so would cause the framework to terminate. The other bundles in an OSGi system are installed into the framework and started as needed. The set of installed bundles in a framework is per- sisted form run to run – when the framework is shut down and relaunched, the same set of bundles is present and started in the new framework. [25] There are number of OSGi framework implementations available from product vendors. In the scope of this thesis we work with Eclipse Equinox [9]. 12 3. THE ECLIPSE RICH CLIENT PLATFORM 3.2.2 The SWT framework SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the userinterface facilities of the operating systems on which it is implemented [14]. SWT is the default user interface library used by Eclipse (it was primarily created by IBM for Eclipse). It provides native widgets e.g. buttons and text fields, as well as layout managers. [30] The goal of the SWT is to use these native widgets of the platform whenever possible. The widgets are then accessed by the SWT framework via the Java Native Interface (JNI). JNI enables Java code running in a JVM to call, and to be called by, native application and libraries written in other languages such as C, C++ and assembler. The same approach is adopted by Abstract Window Toolkit (AWT). The advantage of this approach is its high speed and platform- like appearance of these widgets. More about SWT and other userinterface frameworks is outlined in Section4.2. 3.2.3 JFace JFace is a UI toolkit implemented using SWT to handle many common user interface programming tasks. It is window system-independent in bots, its APIs, and implementation. JFace is designed to work with SWT without hiding it. [18] 3.2.4 Other Eclipse APIs Except above-mentioned frameworks there are many other optional frame- works. The list of possibilities differs according to the version of Eclipse platform. [6] More about the Eclipse platforms is outlined in following sections. 3.3 The Eclipse 3.x platform The Eclipse project did not start with the intention of building an RCP. In- stead, its goal was to create a platform for integrating development tools. However, the Eclipse-based IDEs were professional, good-looking, and pol- ished, and they performed well. Maybe these observations lead developers to an idea to use the same framework to build more generic applications. [24] A major step for Eclipse was releasing of Eclipse 3.0. In this release all of the IDE-related interdependencies were eliminated, and many of the 13 3. THE ECLIPSE RICH CLIENT PLATFORM different parts of the UI were opened to customization. The groundwork for dynamic plug-in installation, removal and updating was established with the introduction of an OSGi-based runtime. [24] These improvements caused sharp interest in RCP. 3.4 The Eclipse e4 platform In 2012 there was the first Eclipse release carried the major version number 4. The Eclipse e4 platform can be thought as an opportunity to rationalize the best parts and to fix weak points of the previous Eclipse 3.x APIs. If we attempt to point out the major enhancements we cannot forget the following: • the structure on an Eclipse application is described via a logical model called the application model • the application model can be modified at development and runtime • the application model can be extended • the styling of Eclipse widgets can be configured via external files (CSS file) • the application model is decoupled from its presentation, it allows to use different user interface toolkits (e.g. SWT or JavaFX) [31] 3.5 Eclipse Public License The Eclipse Public License (EPL) is an Open Source software license used by the Eclipse Foundation for its software [7]. The EPL licensed programs can be used, modified, copied and distributed free of charge. There is only one restriction in using EPL-licensed software in modification in the original EPL code which must also released as EPL code. The source code contributed to Eclipse projects is free of Intellectual Property issues. All above mentioned make reusing the source code of Eclipse projects (e.g. RCP platform) attractive for any kind of software project. 3.6 The Eclipse RCP conclusion The Eclipse RCP in version 4.x is based on state of the art technologies (e.g. CSS styling, dependency injection, etc.). It allows developers to create 14 3. THE ECLIPSE RICH CLIENT PLATFORM standalone applications without necessity to implement a common user interface elements and features. The saved time can be utilized in plugin functionality development. The basic building block is the modularity infrastructure supplied by Equinox by adding comprehensive GUI frameworks and facilities, sophisti- cated provisioning infrastructure, user assistance and many more elements found in common applications. In short, it is all the development teams need to create an application but do not want to write yourself. 15 Chapter 4 The frameworks selection In this chapter we compare notable Eclipse platforms and graphical user interface frameworks. On the basis of the comparison we select the most suitable Eclipse platform and GUI framework in which a new GUI for the PRISM model checker should be implemented. 4.1 The Eclipse RCP platform selection In the previous chapter we introduced two Eclipse RCP platforms (3.x and e4). The first step to the PRISM plugin was to select in which platform the future plugin should be implemented. E4 RCP consists of the new e4 specific technology combined with well- proven frameworks like SWT and JFace. Even the numbering of RCP plat- form prompts that e4 should be technical successor for Eclipse 3.x, but not always is step to a new version of program, framework or platform the best improvement. In the following text we provide reasons leading us to choose Eclipse e4 as bearing platform for the PRISM plugin. 4.1.1 The framework The Eclipse 3.x RCP framework can be compared to a big scaffold that developers use to build an application with. However, this scaffold never goes away and it surround the application forever. [19] In the Eclipse 3.x RCP concept developers typically extend or implement a class and implement the required methods and because you need to do that, the scaffold needs to stay in place. Another drawback can be found in the impossibility of code reusing. Written code is strictly bound to Eclipse RCP framework. In Eclipse e4 you do not extend or implement framework classes because the framework works strictly with Plain Old Java Objects (POJO) [19] In addition all hooks into the framework are based on annotations which are completely ignored if used outside of Eclipse e4. 16 4. THEFRAMEWORKSSELECTION 4.1.2 Dependency injection In Eclipse 3 RCP developers must know API in the very advance way to comfortably interact with the features of the framework. E4 provides differ- ent approach: Dependency Injection (DI). The e4 components are managed by the DI manager. The concept is quite simple: the various components of the e4 framework are maintained by a parented hashmap (DI context) that contains all object instances that the DI framework can inject. On the top of it, DI also allows to create and maintain your own components. More about DI can be found in [8]. 4.1.3 The dynamic application model E4 uses a dynamic in-memory model of the running application enables to create, change and destroy model elements at run-time. In Eclipse 3 RCP it is very difficult to hide views from users. For hiding some context some guarding code was necessary. In Eclipse e4 the user interface can be even completely generated at run-time from an empty model. More about application model is provided in Section 5.3. 4.1.4 GUI independence We already mentioned that Eclipse and SWT are strongly connected. How- ever, e4 equipped Eclipse with a GUI independent rendering framework. This news comes with several experiments with alternative engines (e.g. JavaFX and Swing). [27–29] This promises to take the framework developers already know and love to render outside of the desktop. During the devel- opment of the plugin we tried out prove of the concept [29] implemented by Kai Todter.¨ The result of the execution of sample application rendered in Swing framework can be seen in 4.1. More about Swing rendering frame- work and its possible application during the development of the plugin is discussed in next sections. 4.2 The user interface framework selection In the previous section we discussed Eclipse platforms. We found out that Eclipse e4 is better platform for the PRISM Eclipse plugin because it is based on state of the art technologies and allow developers to use different user interface frameworks. We also know that original PRISM’s GUI is implemented in Swing. 17 4. THEFRAMEWORKSSELECTION Figure 4.1: Swing e4 rendering engine In this section we outline and compare the three main Java user interface toolkits: • Abstract Window Toolkit – first and the simplest framework • Swing – built on AWT, peerless components • Standard Widget Toolkit (SWT) and JFace – SWT is a native widget UI toolkit, JFace is a UI toolkit using SWT to handle many common UI programming tasks 4.2.1 Abstract Window Toolkit (AWT) AWT can be marked as one of the oldest platform dependent UI frameworks. The default implementation of AWT used a ”peer” approach, in which each Java GUI widget had a corresponding component in the underlying windowing system. The implementation of the peer was hidden inside the low-level implementation of the Java Virtual Machine (JVM); the Java- level code stayed identical across platforms. It caused that only features offered by all of the native windowing systems were available in AWT. This required developers to develop their own high-level widgets for more advanced features, and left users with varied experiences. As a consequence, 18 4. THEFRAMEWORKSSELECTION applications developed with AWT lacked many of the features of a modern GUI. [32] 4.2.2 The Swing framework We have already mentioned that PRISM’s GUI is implemented by using Swing framework. In this place we try to sum up the developers experiences and advantages of using the Swing framework. The Swing component set was originally created because the basic AWT components were insufficient for real-based applications. The Swing compo- nent set offers replacements for each of the AWT components and a whole lot more besides. Swing is part of Java standard API so there is no need for additional native libraries. The behavior is the same on all platforms (platform inde- pendence). Rendering Swing components is slower than rendering AWT components because they are drawn from scratch (Swing classes define how to draw Swing controls from scratch). 4.2.3 The Standard Widget Toolkit (SWT) SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the userinterface facilities of the operating systems on which it is implemented [14]. Contrary to both aforementioned frameworks SWT is not part of the Java standard API. SWT tries to combine the best of AWT and Swing. Contrary to Swing it uses less memory and run faster. Because of its cooperation with underlying operating system a change happen to the operating system is automatically updated to SWT GUI widgets. The biggest disadvantage of SWT can be requirement of native libraries for each supported system, and in contrast to Java paradigm of automatic resources disposal, necessity of explicit de-allocating exploited resources by the programmer. 4.2.4 JFace and SWT SWT provides raw widgets with a straightforward API, JFace built on top of SWT provides an abstraction layer, so instead of programming directly to the API, developers program to the abstraction layer. The relation between JFace and SWT can be compared with the relation between Swing and AWT. 19 4. THEFRAMEWORKSSELECTION 4.2.5 The user interface frameworks conclusion In previous sections we summarized the most important facts about user interface frameworks. Essentially we split frameworks into two groups: initial toolkits (AWT and SWT) and subsequent toolkits (Swing and JFace). While initial toolkits were underpowered, subsequent offers in connec- tion with initial toolkits universal frameworks for user interfaces. The most discussed question among Java developers in this context is the question whether Swing or SWT/JFace is better. The answer is not clear and depends on the development team and its preferences as well as on the program for which UI should be implemented. In our case we have an existing application with GUI implemented in Swing, on the other hand we chose Eclipse e4 platform that is primarily adherent with SWT/JFace. In the Section 4.1.4 we introduced Eclipse e4 platform as GUI framework independent. However, the fact that rendering in other GUI frameworks was created as proof of the concept and there are not many mentions of Swing rendering framework among Eclipse e4 developers, lead us to persuade that independence on graphical framework is good step forward, but by far not the most important. Another disadvantage is impossibility of styling of the Swing component via CSS, which is one of the main allurements for implementation in Eclipse e4 framework, more about styling is described in 5.9. Eclipse 3.x Eclipse e4 SWT/JFace obsolete platform, func- functionalities have to be tionalities have to be reim- reimplemented in SWT plemented in SWT Swing not supported experimental projects for integrating Swing widgets in e4 platform, CSS styling impossibility Table 4.1: Platforms and user interface frameworks comparison In Table 4.1 we provide small comparison between Eclipse platforms and frameworks. From the table we can find out that Eclipse 3.x is not suitable for implementation of a new plugin because Swing components cannot be reused and if we decided to reimplement GUI functionalities in SWT we have another choice to exploit state of the art platform (Eclipse e4). 20 4. THEFRAMEWORKSSELECTION Once we have excluded Eclipse 3.x platform we had to compare available GUI frameworks and their relationship to Eclipse e4. SWT/JFace is default user interface framework for Eclipse e4 platform, disadvantage is in the necessity of reimplementing all functionality in this framework (e.g. syntax highlighting). On the other hand reusing of Swing components in the Eclipse e4 platform is possible but because it is not a native Eclipse GUI framework we have to use additional libraries or experimental projects. From the above-mentioned analysis we decided to implement a new graphical user interface in the Eclipse e4 framework and as the main graph- ical user interface framework we have selected SWT. Further, we wanted to reuse the existing GUI components, so we worked with integration of Swing components in SWT widgets. In the following text we describe main development steps. 21 Chapter 5 Implementation of the PRISM Eclipse plugin In this chapter we describe the most important implementation steps of the PRISM Eclipse plugin development. At the end we summarize achieved results of the development. 5.1 IDE and installation of e4 tools The best way, if not only way, to create an Eclipse RCP application is in Eclipse SKD [15]. To ease creating e4 application it is also recommended to download e4 tools. Tools provide wizards to create e4 artifacts and the specialized model editor for the application model. More about installing e4 tools can be found in [5]. 5.2 New project creation The easiest way to create a new RCP application is via wizard that is part of Eclipse e4 tooling project. It creates an executable application with sample contest. Then, this application can be modified to fulfill development team requirements. The other way is by defining the structure of Eclipse e4 application separately. The following list contains required configuration files: • MANIFEST.MF - contains the OSGi configuration information (defini- tion of API and its dependencies, e.g. Java packages or plug-ins which are required by the RCP) • plugin.xml - contains information about Eclipse specific extension mech- anisms (possibility to create and contribute to Eclipse specific API, e.g. extension points and extensions – for example CSS styling) [31] Both configuration files can be modified in text format or via e4 tools. In 5.1 we can see editing of plugin.xml via the e4 tool and in a text editor. 22 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN (a) A tool definition (b) A text representation Figure 5.1: E4 tooling example 5.3 Application model Eclipse e4 uses an abstract description, called the application model to describe the structure of an application. Before we describe the application model of the PRISM Eclipse plugin we have to deal with the design of new GUI. PRISM is well known application and it is one of the reasons why we decided to preserve the original design in new plugin as well. We have to also emphasize that application model can be modified on the run of the application, it means that if anyone do not like the appearance of the plugin it can be modified as needed. Customization can be done via simple drag and drop feature. All applica- tion elements are implemented as draggable windows, it means they can be dragged inside main application window or outside. One application then can look similar to Figure 5.2. It is very useful feature for support of multiple monitors or both graphical and textual editing at one time. In context of the original PRISM application we can have all GUI tabs opened simultaneously, we can simply have opened text editor, properties editor while we can read logs in log window. In Eclipse e4 platform application model is described via XMI file (XML Metadata Interchange). This XMI file is read at application startup and is used to construct the initial application model. [31] In Figure 5.3 there is shown the Eclipse PRISM plugin application model opened in e4 tools editor. If we should summarize features which could be defined via the application model we should point out the following: • Handlers – in Handlers we create connection between command and class responsible for handling the command, e.g. if there is a command for opening a model in text editor with id command.openModel and there is a class OpenModel.java we create a handler for opening a model, if 23 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN Figure 5.2: Customization of application model command is called framework finds a associated handler and execute method in defined class. • Commands – definition of all commands in the application, for every feature there must be an entry. • Windows – in Windows there is a definition of the application structure, i.e. definition of menus, tabs, shared elements etc. For every defined element application model allows to define its label, its unique id or an icon. The link between model element and its implementation is made via Uniform Resource Identifiers (URI). URI describes the location of the Java class. There is difference between link of menu item and window part. Regarding windows, they are directly linked to the implementation. In our example we connect part with ID: prism.propertiespart to Java class: PropertiesPart.java, that is in package userinterface.pluginui.parts of the plug-in called prism. [31] Menu items require different manipulation, menu items are not linked directly to the responsible implementation but to the command, which has to be handled by a handler, as we described above. The referred class is instantiated by the framework only when the model element is activated. To handle application life cycle and to preserve simple structure of the application, annotations are utilized. 24 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN Figure 5.3: The Eclipse PRISM plugin application model 5.4 Annotations We have already pointed out that Eclipse e4 platform is not based on inheri- tance. To identify which method of class, that is connected to a part, should be called at certain time we use behavior annotations. The following annotations are commonly used in Eclipse e4 platform: • @PostConstruct – method is called after the class is constructed • @PreDestroy – method is called before the class is destroyed • @Focus – the method is called once the Part to which class is connected gets the focus • @Persist – method is called if a save request on the Part to which class is connected is triggered • @PersistState – method is called before the object is disposed, so that the part is able to save its instance state An example with behavior annotation is in Figure 5.4. Next to the above- mentioned annotations there is @Execute annotation. This annotation should mark the method which is responsible for the action of the handler class. The framework executes this method once related UI element is selected. 25 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN import javax.annotation.PostConstruct; //the method is called after the class is constructed @PostConstruct public void createMethod(Composite parent) { System.out. println(this . getClass ().getSimpleName() + ” called.”); } Figure 5.4: A @PostConstruct method example 5.5 GUI elements implementation Once we had defined the application model we had to implement a content of each element (e.g. parts, handlers, etc.). In this moment of development we had to make a difficult decision in which framework the content of each part should be implemented. From the previous text we were not able to decide which framework (SWT or Swing) is better. We only knew that PRISM is written in Swing and SWT is default user interface library used by Eclipse. During the development we decided to try both frameworks in Eclipse e4 platform (i.e. we wanted to implement a model editor) and on the basis of achieved experiences we wanted to implement the remaining functionality in the chosen framework. 5.5.1 SWT and JFace For implementing SWT elements we used SWT designer (see Figure 5.5). SWT designer is part of WindowBuilder [16] and is built as a plug-in to Eclipse. This tool makes easy to create Java GUI applications without spend- ing a lot of time writing code. It is simple drag-and-drop editor which generates the Java code. In context of Eclipse e4 RCP the code is generated in method that is annotated with @PostConstruct. From the provided SWT widgets we selected a StyledText for the model editor. The StyledText is an editable user interface object that displays lines of text. There are two ways to create a comparable editor to the PRISM’s one. The first one is directly by methods of the StyledText: implementing of line style listeners, key words etc. The other way is by some development framework. One of the best known is Xtext [17]. Xtext is a framework for development of programming languages and domain specific languages. 26 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN Figure 5.5: SWT designer 5.5.2 Swing Contrary to SWT when we worked with Swing we had to first find out the way the Eclipse e4 components can co-work with Swing components, for example with JEditorPane (PRISM’s editor is implement as JEditorPane). We found out that there exists a technique how to add a Swing com- ponent inside SWT widget. It can be done via a SWT AWT class (part of org.eclipse.swt.awt package). This class provides a bridge between SWT and AWT, so that it is possible to embed AWT components in SWT and vice versa. Note that Swing is built on AWT. The process of embedding a JEditorPane in SWT component is described in Figure 5.6. In the example we can see that even so simple task as is em- bedding one Swing component in SWT widget can be unclear. The situation become worse when we want to add not only editor, but scroll bar, handler etc. According to our opinion the analysis shows that there are some issues with both frameworks. While implementing all GUI features in SWT will take monumental effort and disable an opportunity to maintain source code of the PRISM GUI and Eclipse PRISM plugin GUI at once, embedding Swing components in SWT widgets infringe readability and maintainability of the source code but we reuse the existing code. 27 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN //imports import java.awt.Frame; import javax.annotation.PostConstruct; import org. eclipse .swt.awt.SWT AWT; import org. eclipse .swt.widgets.Composite; import javax.swing.JEditorPane; import javax.swing.JScrollPane; // c l a s s private JEditorPane editorScrollPane; private JEditor editor; @PostConstruct public void createControls(Composite parent) { Composite composite = new Composite(parent ); editor = new JEditorPane() { //override methods } editorScrollPane = new JScrollPane(editor ); Frame frame = SWT AWT. new Frame(composite ); frame.add(editorScrollPane ); frame.add(handler ); frame.add(editor ); } Figure 5.6: Embedding a Swing component in SWT widget 5.6 Swing components integration We have already discussed possibility to embed swing components in SWT widgets, in reality there must be done much more to make the integration more consistent. 5.6.1 Multiple Event Threads Each UI toolkit has its own event queue, and each event queue is processed by a separate thread. [13]. It means that most of Swing/SWT APIs must be called from its event thread, opposite approach leads to erroneous behaviour of API elements. To schedule work of both coexisting threads we have to call invoke- Later() and invokeAndWait() [26] methods for AWT (Swing) event thread and 28 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN jawa.awt.Dialog constantPicker = new GUIConstantsPicker(params); S h e l l s h e l l = new S h e l l ( parent , SWT.APPLICATION MODAL | SWT. NO TRIM ) ; shell.setSize(0 ,0); shell . addFocusListener(new FocusAdapter() { public void focusGained(FocusEvent e) { constantPicker .requestFocus (); constantPicker.toFront (); } } ); Figure 5.7: Opening a modal SWT dialog while the Swing dialog is showing asyncExec() and syncExec() [4] methods for SWT event thread. The use of multiple event threads increases risk of deadlock and adds complexity to the code. 5.6.2 Look and feel SWT components are underlying native widgets which have a native look and feel it means that Swing look and feel must be changed to match the native platform. 5.6.3 Application Flickering Embedded AWT frames causes excessive flickering while the application window is resized. The reasons are in AWT implementation, that by default, clears the component’s background on every resize event and in the fact that more resize events have to be handled by the embedded frame due to the way resize events are passed on the AWT frame from the enclosing SWT composite. [13] 5.6.4 Modal dialogs One of the most chalenging tasks is to make Swing modal dialogs responsive. When a modal dialog is opened from a Swing component, it must be modal across the entire application. [13] Since SWT and AWT have separate event threads, such dialogs are not modal by default, it causes that we can see such dialogs but they are not responding on any event (mouse, keyboard 29 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN event etc.). The SWT event thread must be explicitly disable during the time that a Swing modal dialog is showing. According to the [13] the easiest solution is to open a modal SWT dialog while the Swing dialog is showing (see 5.7). This process can be utilized only when we are able to modified Swing component library or we can introduce dependencies on SWT code from the Swing component library. Alternative approach is to enforce correct modal behaviour by installing a listener for AWT window events. Whenever it is detected that a Swing modal dialog is open or visible, a SWT modal dialog must be opened. The existing implementation of such listener is the Albireo [3] project; more about this project is discussed below. 5.6.5 Pop-up menus dismissing When a context menu is displayed in an embedded AWT (Swing) frame, the menu does not disappear after clicking outside the frame. This AWT limitations is well known, but it is especially noticeable in embedded frames since it may result in multiple pop-ups within the same SWT shell. [13] 5.6.6 Keystroke logging Once we can have two maps for keystrokes in the RCP application (map of global actions in RCP and map of embedded Swing component) there can occur unexpected results when we map the same keystroke to the global action and to a handler. Avoiding this kind of conflict can be done by using org.eclipse.ui.contexts extension point in Application model of the plugin, or by replication the Swing component’s actions in RCP actions, bound to the same keystroke. This approach may be necessary anyway, if we want the action to be available anywhere outside the Swing components (e.g. in the application’s main menu). [13] 5.6.7 Albireo project To facilitate encapsulation of Swing components in an SWT control and to deal with above-mentioned integration issues Albireo project was intro- duced. From the documentation [3] is not clear how to use this project, docu- mentation describes some basics and the Albireo installation. That is the reason we provide here the core steps. 30 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN import org. eclipse . albireo .core.SwingControl; @PostConstruct public void postConstruct(params) { swingControl = new SwingControl(parent , SWT.NONE) { protected JComponent createSwingComponent() { return PrismEclipsePlugin.getSim(); } @Override public Composite getLayoutAncestor() { return parent; } } ; Figure 5.8: Part code example After installation, when the plugin starts new instance of AwtEnviroment should be retrieved. Initialization includes setting the appropriate look and feel and registering the necessary listeners to ensure proper behaviour of modal dialogs. For parts classes (i.e. Simulator, Properties tabs) the SwingControl class does all the work. Example of the code can be seen in 5.8. It requires imple- menting two methods: • createSwingComponent(params) – method in which a Swing component is created • getLayoutAncestor() – method returning parent of a new SwingControl For handlers classes we need to block SWT events when we call some Swing functionalities. It can be reached by calling invokeAndBlockSwt(param) method. Example is provided in 5.9. This method invokes the given runnable in the AWT event thread while blocking user input on the SWT event thread. 5.7 Eclipse plugin packages Due to the application model and best practices among e4 framework devel- opers we created the following packages for the plugin’s code: • userinterface.pluginui – contains implementations of the main classes of the plugin 31 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN package userinterface .pluginui.handlers; import org. eclipse . albireo .core.AwtEnvironment; import org. eclipse .e4.core.di.annotations.Execute; import org. eclipse .e4.ui.model. application .MApplication; import org. eclipse .swt.widgets.Shell; import userinterface .pluginui.PrismEclipsePlugin; public class SimulateHandler { @Execute public void execute() { AwtEnvironment awtInstance = PrismEclipsePlugin .getAwtInstance (); awtInstance .invokeAndBlockSwt(new Runnable() { public void run() { PrismEclipsePlugin.getProps (). a simulateSelected (); } } ); } } Figure 5.9: Handler code example • userinterface.pluginui.handlers – implementations of handlers, i.e. classes responsible for handling commands called from the plugin • userinterface.pluginui.parts – contains classes with implementations for parts, i.e. for Model, Simulator, Properties and Log We have added packages for Albireo project as well: • org.eclipse.albireo.core – contains AwtEnvironment and SwingCotrol classes • org.eclipse.albireo.internal – internal classes for core package 5.8 Plugin core classes The main class of the plugin is PrismEclipsePlugin, this class is implemented as a singleton (i.e. there exists only one instance). In constructor all important Swing components are instantiated. The second important class is PrismE- clipsePluginHandler. This handler is an alternative to Swing handler handling all events from the GUI. 32 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN 5.9 Cascading style sheets (CSS) In Chapter 2 we dealt with the look and feel of the original PRISM that depends on Swing components. The Eclipse e4 platform allows to style applications via CSS. CSS allows developers to define styles, layouts and spacing separately from the content which should by styled. CSS is defined as a standard. Currently the versions CSS 2.1 and CSS 3 are most widely used. [31] Syntax of CSS standard is following: selector{property : value}; A selector can be one of a predefined unique identifier (e.g. Label, Com- posite, etc.). The Eclipse platform supports static as well as dynamic styling of an application. In the case of static styling the styling cannot be exchanged at runtime, while in the case of dynamic styling it is possible to switch the styling at runtime. The concept of CSS styling in Eclipse is great idea but it has its limitations. SWT as the default user interface toolkit of Eclipse has certain limitations with regards of styling components, which are based on the limitations of the underlying operating system (e.g. it is not possible to style menus and table headers because this is not supported by the SWT implementation). For more about application styling see [31]. 5.10 Exporting and platform independency When the application is implemented and ready to be published it has to be exported. Exporting is one of the most important steps for the application but in the scope of the Eclipse RCP one of the trickiest. In order to create an application that can run on several platforms it must be built and exported for multiple platforms. In the scope of Eclipse e4 we speak about Delta pack. Delta pack is a zipped Eclipse package with all the needed to export a RCP product to many platforms (Windows, Linux, Mac, and so on) without having to do that on a platform’s native Eclipse installation. Once the Delta pack is installed on a running platform, export can be done via the Export Product wizard. The wizard with available platform can be seen in Figure 5.10. 33 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN Figure 5.10: Export product wizard 5.11 The Eclipse PRISM plugin conclusion In the scope of this chapter we firstly outlined the structure of the selected platform. We also compared notable Java GUI frameworks, however, we weren’t able to answer the question in which framework the Eclipse PRISM plugin should be implemented. That is why we decided to examine both (SWT and Swing) frameworks in implementation of basic features. During the examination we kept in mind that we can reuse implemented features from the original PRISM. From the experimental implementation we discov- ered that starting from scratch is not a good idea because even simple tasks require enormous effort. On the other hand we found out that Swing com- ponents and their embedding in the Eclipse e4 RCP comes with additional overhead and breaks the idea of uniform GUI. However, after identifying critical points of embedding existing Swing components in SWT widgets we 34 5. IMPLEMENTATION OF THE PRISMECLIPSEPLUGIN decided to finish implementation in this way. In the moment this thesis is written we were not able to export the application without error, there are too many dependencies and quite a lot of ways how this dependencies should be defined. It means that application runs only locally in the Eclipse SKD. The up-to-date source code of the application is available in the PRISM Eclipse plugin repository. 35 Chapter 6 Future work In this chapter we point out several improvements which should be done when application will be successfully exported. 6.1 Building via Maven In software development the term building usually means the conversion of source code and other artefacts, like images or configuration files, into another artefact. For example source code might be compiled into a new standalone application. The Tycho project [22] provides a set of Maven plug- ins for building Eclipse components via the command line. 6.2 Continuous integration to SWT The embedding of Swing component in SWT widgets is usually considered as transition point toward new implementation. The selected approach of the plugin implementation allows coexisting both discussed graphical framework in one application. It means that when some component will be obsolete and it will be required to reimplement it, there is no need to reimplement the whole application but only this component, and the only think that has to be done is to select a graphical framework (e.g. SWT). 36 Chapter 7 Conclusion The goal of this thesis was to analyse available Eclipse platforms and no- table graphical user interface frameworks, an on the basis of the analysis to implement a new graphical user interface for the PRISM model checker allowing all functionality of the current PRISM GUI. Because of preferences of the original development team to develop an Eclipse plugin we analysed Eclipse 3.x and Eclipse e4 platforms in detail. We also deal with graphical frameworks at large and on the basis of the analyses we suggest suitable technologies for the implementation. During the implementation of the plugin we discovered that implemen- tation of plugin in SWT requires enormous effort and beyond, all changes made in original PRISM in Swing have to be reimplemented in SWT as well. Regarding the embedding of Swing components in Eclipse e4 platform, we have to summarize that this practice comes with additional overhead and breaks the idea of uniform GUI of the Eclipse e4 application. However, due to external tool (Albireo), the integration is possible. From the abovementioned we decided to implement the whole applica- tion by embedding existing components in SWT widgets. Application has been successfully implemented with the exception of successful exporting of the application. 37 Chapter 8 Source code information The up-to-date source code of the Eclipse plugin can be found in the SVN repository of the Eclipse plugin branch /branches/prism-eclipse-plugin on URL: https://www.prismmodelchecker.org/svn/prism/prism. If any credentials are needed, please contact the original development team to grant access. 38 Bibliography [1] PRISM Case Studies. http://www.prismmodelchecker.org/ casestudies/index.php. [Online; Accessed: 2015-04-21]. [2] OSGiTM Alliance. The OSGi Architecture. http://www.osgi.org/ Technology/WhatIsOSGi. [Online; Accessed: 2015-04-18]. [3] The Eclipse Foundation. Albireo Project. http://wiki.eclipse. org/Albireo_Project. [Online; Accessed: 2016-01-07]. [4] The Eclipse Foundation. Class Display. http://help.eclipse. org/juno/index.jsp?topic=%2Forg.eclipse.platform. doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt% 2Fwidgets%2FDisplay.html. [Online; Accessed: 2016-01-06]. [5] The Eclipse Foundation. E4/Install. https://wiki.eclipse.org/ E4/Install. [Online; Accessed: 2015-05-22]. [6] The Eclipse Foundation. Eclipse platform api specification. http://help.eclipse.org/indigo/index.jsp?topic= %2Forg.eclipse.platform.doc.isv%2Freference%2Fapi% 2Findex.html. [Online; Accessed: 2015-05-16]. [7] The Eclipse Foundation. Eclipse public license - v 1.0. http://www. eclipse.org/org/documents/epl-v10.php. [Online; Accessed: 2015-04-18]. [8] The Eclipse Foundation. Eclipse4/RCP/Dependency Injection. https://wiki.eclipse.org/Eclipse4/RCP/Dependency_ Injection. [Online; Accessed: 2015-05-17]. [9] The Eclipse Foundation. Equinox. http://eclipse.org/ equinox/. [Online; Accessed: 2015-05-16]. [10] The Eclipse Foundation. Jface. https://wiki.eclipse.org/ JFace. [Online; Accessed: 2015-04-18]. 39 8. SOURCE CODE INFORMATION [11] The Eclipse Foundation. Programming Languages. https: //marketplace.eclipse.org/taxonomy/term/1966%2C31/ title. [Online; Accessed: 2015-05-16]. [12] The Eclipse Foundation. RCP Applications. https://marketplace. eclipse.org/category/markets/rcp-applications/title. [Online; Accessed: 2015-04-18]. [13] The Eclipse Foundation. Swing/SWT Integration. http: //www.eclipse.org/articles/article.php?file= Article-Swing-SWT-Integration/index.html. [Online; Accessed: 2016-01-05]. [14] The Eclipse Foundation. SWT: The Standard Widget Toolkit. http: //www.eclipse.org/swt/. [Online; Accessed: 2015-04-18]. [15] The Eclipse Foundation. The Eclipse Project Downloads. http: //download.eclipse.org/eclipse/downloads/. [Online; Ac- cessed: 2015-05-22]. [16] The Eclipse Foundation. WindowBuilder - is a powerful and easy to use bi-directional Java GUI designer. https://eclipse.org/ windowbuilder/. [Online; Accessed: 2015-05-23]. [17] The Eclipse Foundation. Xtext - Overview. http://www.eclipse. org/Xtext/documentation/index.html. [Online; Accessed: 2015-05-23]. [18] J. Li Guojie. Prefessional Java Native Interfaces with SWT/JFace. John Wiley & Sons, 2005. ISBN 0-470-09459-1. [19] W. Jongman. Why Eclipse e4? (the Egg Laying Woolmilkpig). http://industrial-tsi-wim.blogspot.cz/2012/10/ why-eclipse-e4-egg-laying-woolmilkpig.html. [Online; Accessed: 2015-05-17]. [20] M. Kwiatkowska, G. Norman, and D. Parker. PRISM: Probabilistic model checking for performance and reliability analysis. SIGMETRICS Perform. Eval. Rev., 36(4):40–45, March 2009. [21] M. Kwiatkowska, G. Norman, and D. Parker. PRISM 4.0: Verification of probabilistic real-time systems. In G. Gopalakrishnan and S. Qadeer, editors, Proc. 23rd International Conference on Computer Aided Verifi- cation (CAV’11), volume 6806 of LNCS, pages 585–591. Springer, 2011. 40 8. SOURCE CODE INFORMATION [22] L.Vogel and S. Sholz. Eclipse Tycho for building Eclipse Plug-ins and RCP applications - Tutorial . http://www.vogella.com/ tutorials/EclipseTycho/article.html. [Online; Accessed: 2016-01-07]. [23] P. Manickam, S. Sangeetha, and S. Subrahmanya. Component-Oriented Development and Assembly: paradigm, principles, and practice using Java. CRC Press, 2014. ISBN 978-1-4665-8100-5. [24] J. McAffer, J. Lemieux, and C. Aniszczyk. Eclipse Rich Client Platform. Pearson Education, second edition, 2010. ISBN 978-0-321-60378-4. [25] J. McAffer, P. VanderLei, and S. Archer. OSGi and Equinox: creating highly modular Java systems. Pearson Education, 2010. ISBN 0-321- 58571-2. [26] Oracle. Class SwingUtilities. https://docs.oracle.com/ javase/6/docs/api/javax/swing/SwingUtilities.html. [Online; Accessed: 2016-01-06]. [27] T. Shindl. e(fx)clipse. http://www.eclipse.org/efxclipse/ index.html. [Online; Accessed: 2015-05-17]. [28] RAP team. E4/RAP Integration/Experimental. http://wiki. eclipse.org/E4/RAP_Integration/Experimental. [Online; Accessed: 2015-05-17]. [29] K. Toedters. e4-rendering. https://github.com/toedter/ e4-rendering. [Online; Accessed: 2015-05-17]. [30] L. Vogel. Swt - tutorial. http://www.vogella.com/tutorials/ SWT/article.html. [Online; Accessed: 2015-05-14]. [31] L. Vogel. Eclipse 4 Application Development: The complete guide Eclipse 4 RCP development. Lars Vogel, June 2012. ISBN 389- 3943747034. [32] R. Warner and R. Harris. The Definitive Guide to SWT and JFace. Apress, 2004. ISBN 1-59059-325-1. [33] www.prismmodelchecker.org. Debugging Models With The Simulator. http://www.prismmodelchecker.org/manual/ RunningPRISM/DebuggingModelsWithTheSimulator. [Online; Accessed: 2015-05-22]. 41 8. SOURCE CODE INFORMATION [34] www.prismmodelchecker.org. PRISM Benchmark Suite - Properties (CTMCs). http://www.prismmodelchecker.org/benchmarks/ props-ctmc.php. [Online; Accessed: 2015-05-12]. [35] www.prismmodelchecker.org. PRISM Manual. http://www. prismmodelchecker.org/manual/Main/Welcome. [Online; Ac- cessed: 2015-05-19]. [36] www.prismmodelchecker.org. Property Specification / Intro- duction. http://www.prismmodelchecker.org/manual/ PropertySpecification/Introduction. [Online; Accessed: 2015-05-22]. [37] www.prismmodelchecker.org. Wireless Communication Cell. http:// www.prismmodelchecker.org/casestudies/cell.php. [On- line; Accessed: 2015-05-12]. 42
PRISM Model Checker As an Eclipse-Plugin
