LABEL DESIGNING FOR MINIMALLY PROCESSED TILAPIA AIMING THE TRACEABILITY OF THE PRODUCTIVE CHAIN

The aim of this study was to develop label for Nile tilapia minimally processed. Analyses were performed to quantify the nutritional components of the fillets; and information about freshness, date of processing and batch specification was collected. Such data were essential for designing labels providing information about the traceability system and presenting codes for quality identification such as the Quick Response Code (QR Code), which allows the electronic encoding of the product on a database. Mandatory food labeling associated with the use of QR Code are tools that convey information to consumers about food quality and the entire production chain. One hundred sixty-two potential consumers were surveyed about the general characteristics of the product packaged in poly nylon film type, vacuum-packed, used for the packaging of traced fresh-cut fillets of tilapia minimally processed and kept under refrigeration (0±1oC). According to the Spearman correlation the variables packaging, general appearance and willingness to purchase the product presented a correlation, with coefficients estimated at 0.437, 0.466 and 0.497 respectively

Cross-level Validation of Topological Quantum Circuits

Quantum computing promises a new approach to solving difficult computational problems, and the quest of building a quantum computer has started. While the first attempts on construction were succesful, scalability has never been achieved, due to the inherent fragile nature of the quantum bits (qubits). From the multitude of approaches to achieve scalability topological quantum computing (TQC) is the most promising one, by being based on an flexible approach to error-correction and making use of the straightforward measurement-based computing technique. TQC circuits are defined within a large, uniform, 3-dimensional lattice of physical qubits produced by the hardware and the physical volume of this lattice directly relates to the resources required for computation. Circuit optimization may result in non-intuitive mismatches between circuit specification and implementation. In this paper we introduce the first method for cross-level validation of TQC circuits. The specification of the circuit is expressed based on the stabilizer formalism, and the stabilizer table is checked by mapping the topology on the physical qubit level, followed by quantum circuit simulation. Simulation results show that cross-level validation of error-corrected circuits is feasible.Comment: 12 Pages, 5 Figures. Comments Welcome. RC2014, Springer Lecture Notes on Computer Science (LNCS) 8507, pp. 189-200. Springer International Publishing, Switzerland (2014), Y. Shigeru and M.Shin-ichi (Eds.

Test Set Diameter: Quantifying the Diversity of Sets of Test Cases

A common and natural intuition among software testers is that test cases need to differ if a software system is to be tested properly and its quality ensured. Consequently, much research has gone into formulating distance measures for how test cases, their inputs and/or their outputs differ. However, common to these proposals is that they are data type specific and/or calculate the diversity only between pairs of test inputs, traces or outputs. We propose a new metric to measure the diversity of sets of tests: the test set diameter (TSDm). It extends our earlier, pairwise test diversity metrics based on recent advances in information theory regarding the calculation of the normalized compression distance (NCD) for multisets. An advantage is that TSDm can be applied regardless of data type and on any test-related information, not only the test inputs. A downside is the increased computational time compared to competing approaches. Our experiments on four different systems show that the test set diameter can help select test sets with higher structural and fault coverage than random selection even when only applied to test inputs. This can enable early test design and selection, prior to even having a software system to test, and complement other types of test automation and analysis. We argue that this quantification of test set diversity creates a number of opportunities to better understand software quality and provides practical ways to increase it.Comment: In submissio

Using formal methods to develop WS-BPEL applications

In recent years, WS-BPEL has become a de facto standard language for orchestration of Web Services. However, there are still some well-known difficulties that make programming in WS-BPEL a tricky task. In this paper, we firstly point out major loose points of the WS-BPEL specification by means of many examples, some of which are also exploited to test and compare the behaviour of three of the most known freely available WS-BPEL engines. We show that, as a matter of fact, these engines implement different semantics, which undermines portability of WS-BPEL programs over different platforms. Then we introduce Blite, a prototypical orchestration language equipped with a formal operational semantics, which is closely inspired by, but simpler than, WS-BPEL. Indeed, Blite is designed around some of WS-BPEL distinctive features like partner links, process termination, message correlation, long-running business transactions and compensation handlers. Finally, we present BliteC, a software tool supporting a rapid and easy development of WS-BPEL applications via translation of service orchestrations written in Blite into executable WS-BPEL programs. We illustrate our approach by means of a running example borrowed from the official specification of WS-BPEL

Contracts in Practice

Contracts are a form of lightweight formal specification embedded in the program text. Being executable parts of the code, they encourage programmers to devote proper attention to specifications, and help maintain consistency between specification and implementation as the program evolves. The present study investigates how contracts are used in the practice of software development. Based on an extensive empirical analysis of 21 contract-equipped Eiffel, C#, and Java projects totaling more than 260 million lines of code over 7700 revisions, it explores, among other questions: 1) which kinds of contract elements (preconditions, postconditions, class invariants) are used more often; 2) how contracts evolve over time; 3) the relationship between implementation changes and contract changes; and 4) the role of inheritance in the process. It has found, among other results, that: the percentage of program elements that include contracts is above 33% for most projects and tends to be stable over time; there is no strong preference for a certain type of contract element; contracts are quite stable compared to implementations; and inheritance does not significantly affect qualitative trends of contract usage