The launch shortcut for NuSMV 

Contexts in source publication

Context 1

... launchConfigurationTabGroups in the package org.eclipse.debug.ui . It contains the configuration with all the options a user can select when launching NuSMV. 4. We than declare and implement a launch shortcut that allows users to identify a resource in the workbench (either via selection or the active editor) and launch that resource with a single click without bringing up the launch configuration dialog. An example of its use is shown in Fig. ...

Context 2

... Object-Oriented development, developers try to define classes having (i) strongly related responsibilities, i.e., high cohesion, and (ii) limited number of dependencies with other classes, i.e., low coupling [ 1]. Unfortunately, due to strict deadlines, programmers do not always have sufficient time to make sure that the resulting source code conforms to such a development laws [8]. In particular, during software evolution the internal structure of the system undergoes continuous modifications that makes the source code more complex and drifts away from its original design. Classes grow rapidly because programmers often add a responsibility to a class thinking that it is not required to include it in a separate class. However, when the added responsibility grows and breeds, the class becomes too complex and its quality deteriorates [8]. A class having more than one responsibility has generally low cohesion and high coupling. Several empirical studies provided evidence that high levels of coupling and lack of cohesion are generally associated with lower productivity, greater re- work, and more significant design efforts for developers [6], [10], [11], [12], [13]. In addition, classes with lower cohesion and/or higher coupling have been shown to correlate with higher defect rates [9], [14], [15]. Classes with unrelated methods often need to be restruc- tured by distributing some of their responsibilities to new classes, thus reducing their complexity and improving their cohesion. The research domain that addresses this problem is referred to as refactoring [8]. In particular, Extract Class Refactoring allows to split classes with many responsibilities into different classes. Moreover, it is a widely used technique to address the Blob antipattern [8], namely a large and complex class, with generally low cohesion, that centralize the behavior of a portion of a system and only use other classes as data holders. It is worth noting that performing Extract Class Refactoring operations manually might be very difficult, due to the high complexity of some Blobs. For this reason, several approaches and tools have been proposed to support this kind of refactoring. Bavota et. al [2] proposed an approach based on graph theory that is able to split a class with low cohesion into two classes having a higher cohesion, using a MaxFlow-MinCut algorithm. An important limitation of this approach is that often classes need to be split in more than two classes. Such a problem can be mitigated using partitioning or hierarchical clustering algorithms. However, such algorithms suffer of important lim- itations as well. The former requires as input the number of clusters, i.e., the number of classes to be extracted, while the latter requires the definition of a threshold to cut the dendogram. Unfortunately, no heuristics have been derived to suggest good default values for all these parameters. In- deed, in the tool JDeodorant [7], which uses a hierarchical clustering algorithm to support Extract Class Refactoring, the authors tried to mitigate such an issue by proposing different refactoring opportunities that can be obtained using various thresholds to cut the dendogram. However, such an approach requires an additional effort by the software engineer who has to analyze different solutions in order to identify the one that provides the most adequate division of responsibilities. We tried to mitigated such deficiencies by defining an approach able to suggest a suitable decomposition of the original class by also identifying the appropriate number of classes to extract [3, 4]. Given a class to be refactored, the approach calculates a measure of cohesion between all the possible pairs of methods in the class. Such a measure cap- tures relationships between methods that impact class cohesion (e.g., attribute references, method calls, and semantic content). Then, a weighted graph is built where each node represents a method and the weight of an edge that connects two nodes is given by the cohesion of the two methods. The higher the cohesion between two methods the higher the like- lihood that the methods should be in the same class. Thus, a cohesion threshold is applied to cut all the edges having cohesion lower than the threshold in order to reduce spuri- ous relationships between methods. The approach defines chains of strongly related methods exploiting the transitive closure of the filtered graph. The extracted chains are then refined by merging trivial chains (i.e., chains with few methods) with non trivial chains. Exploiting the extracted chains of methods it is possible to create new classes - one for each chain - having higher cohesion than the original class. In this paper, we present the implementation of the proposed Extract Class Refactoring method in ARIES (Au- tomated Refactoring In EclipSe) [5], a plug-in to support refactoring operations in Eclipse. ARIES provides support for Extract Class Refactoring through a three steps wizard. In the first step, shown in figure 1, the tool supports the software engineer in the identification of candidate Blobs through the computing of three quality metrics, namely LCOM5 [6], C3 [9] and MPC [16]. Thus, ARIES does not compute an overall quality of the classes, but it considers only cohesion and coupling as the main indicators of class quality in this context. Hence, Blobs are usually outliers or classes having a quality much lower than the average quality of the system under analysis [9]. The identification of Blobs in ARIES is based on such a conjecture. In the second step of the wizard, the software engineer has the possibility to further analyze a candidate Blob and get insights on the different responsibilities implemented by analyzing its topic map, represented as the five most frequent terms in a class (the terms present in the highest number of methods). For this reason, the topic map is represented by a pentagon where each vertex represents one of the main topics. Once a class that needs to be refactored is identified, the software engineer activates the last step of the wizard (shown in figure 2) to obtain a possible restructuring of the class under analysis. ARIES reports for each class that should be extracted from the Blob the following information: (i) its topic map; (ii) the set of methods composing it; and (ii) a text field where the developer can assign a name to the class. The tool also allows the developer to customize the proposed refactoring moving the methods between the extracted classes. In addition, ARIES offers the software engineer on-demand analysis of the quality improvement obtained by refactoring the Blob, by comparing various measures of the new classes with the measures of the Blob. When the developer ends the analysis, the extraction process begins. ARIES will generate the new classes making sure that the changes made by the refactoring do not introduce any syntactic error. A video of the tool is available on Youtube 1 . [1] W. Stevens, G. Myers, and L. Constantine. Structured design. IBM Systems Journal, vol. 13, no. 2, pp. 115139, 1974. [2] G. Bavota, A. De Lucia, and R. Oliveto. Identifying extract class refactoring opportunities using structural and semantic cohesion measures. JSS , 84:397–414, 2011. [3] G. Bavota, A. D. Lucia, A. Marcus, and R. Oliveto. A two-step technique for extract class refactoring. ASE , 151– 154, 2010. [4] G. Bavota, A. D. Lucia, A. Marcus, and R. Oliveto. Au- tomating Extract Class Refactoring: an Improved Method and its Evaluation. Empirical Software Engineering (EMSE) (2013) To ...

Context 3

... per quantificare e sviluppare programmi di misura per processi e prodotti software, tuttavia è stato dimostrato che il paradigma di quantificazione degli obiettivi è applicabile ad ogni tipo di programma di misura (non solo software) [9]. L’idea alla base di tale approccio è che non esista un metodo universale per misure un prodotto o un processo, esistono delle orientati agli obiettivi (goal-oriented) cosicché la collezione dei dati o delle misure non è pi ù un’ attività fuori controllo ma imbrigliata in un processo quantificabile e tracciabile attraverso una documentazione esplicitamente prodotta. Questo è il motivo per il quale si ritiene che esso è applicabile a Ocop. L'esperimento vede la creazione di una CoP virtuale che unisce due istituzioni accademiche che condividono obiettivi comuni: la Facoltà di Ingegneria dell'Università degli Studi di Napoli "Federico II" (UNFII), e il Dipartimento di Scienze della Kent State University a Stark, Ohio, Stati Uniti (KSU). L'esperimento è stato eseguito nel semestre autunnale 2012 e ha coinvolto circa 100 persone di UNFII e circa 20 di KSU. Esso oltre a produrre risultati tangibili, che consistevano in una raccolta di diversi manufatti e lo sviluppo di un grande progetto, è stato l'occasione per la valutazione del processo di formazione erogato. La valutazione è stata effettuata alla fine dell'esperimento, invitando gli studenti a rispondere a un questionario. Le risposte sono state ricondotte a una scala di 5 valori (espressi in termini di rapporto tra aggettivi e numeri) che sono stati utilizzati per misurare i risultati e analizzarli obiettivamente. Fig. 1 rappresenta ogni domanda con il suo valore medio su una stella a 22 rami di un diagramma di Kiviat. Questo diagramma è utile per evidenziare i punti di forza contro le debolezze del nostro ...

Context 4

... framework proposed in [1] evaluates the performance of a web service by measuring some performance indicators like service time and response time. Figure 1 shows a simpli fi ed version of this framework. Basically, the model of ...

Context 5

... up views (like in Figure 1) only requires a few lines of Java code. Using the DSL (like in Figure 2) the customization of the components is really quick (the corresponding Java code will be automatically generated by the DSL compiler). Concerning the persistence aspect, the framework can handle a generic EMF persistence implementation, like XMI or Teneo, just providing the EMF Resource’s URIs. It also includes a bundle for handling CDO resources, which takes care of CDO sessions and transactions transparently. All sources are covered by tests, both unit tests (with JUnit) and functional tests (with SWTBot). Tests are already integrated in the Continuous Integration system implemented with Jenkins. Also the building and update site architecture is already setup and implemented with Buckminster [8]. This building tool is heav- ily used throughout the whole development cycle, starting from the workspace and platform materialization up to headless building and continuous integration. In addition to be used to render RCP UI, the framework is out- of-the-box ready to be used for RAP development (Remote Application Platform [2]). By using single sourcing techniques, it is easy to develop an RCP application with EMF Parsley and to automatically have a web version (based on RAP) of the same application. EMF Parsley can also be used with the new Eclipse e4 platform. The framework that is closer to our proposal is EMF Client Platform [1]. However, while the latter aims at providing a quick way of obtaining a full application based on EMF, EMF Parsley aims at providing single smaller and reusable components. Moreover, our components are not customized via extension points, but using injection with plain Java and with a DSL. The framework presented here is available at ...