This paper presents techniques to model circular lazy programs in a strict, purely functional setting. Circular lazy programs model any algorithm based on multiple traversals over a recursive data structure as a single traversal function. Such elegant and concise circular programs are defined in a (strict or lazy) functional language and they are transformed into efficient strict and deforested, multiple traversal programs by using attribute grammars-based techniques. Moreover, we use standard slicing techniques to slice such circular lazy programs. We have expressed these transformations as an Haskell library and two tools have been constructed: the HaCirctool that refactors Haskell lazy circular programs into strict ones, and the OCirctool that extends Ocaml with circular definitions allowing programmers to write circular programs in Ocaml notation, which are transformed into strict Ocaml programs before they are executed. The first benchmarks of the different implementations are presented and show that for algorithms relying on a large number of traversals the resulting strict, deforested programs are more efficient than the lazy ones, both in terms of runtime and memory consumption.

Spectrum-based fault localization shortens the test- diagnose-repair cycle by reducing the debugging effort. As a light-weight automated diagnosis technique it can easily be integrated with existing testing schemes. However, as no model of the system is taken into account, its diagnostic accuracy is inherently limited. Using the Siemens Set benchmark, we investigate this diagnostic accuracy as a function of several parameters (such as quality and quantity of the program spectra collected during the execution of the system), some of which directly relate to test design. Our results indicate that the superior performance of a particular similarity coefficient, used to analyze the program spectra, is largely independent of test design. Furthermore, near- optimal diagnostic accuracy (exonerating about 80% of the blocks of code on average) is already obtained for low-quality error observations and limited numbers of test cases. The influence of the number of test cases is of primary importance for continuous (embedded) processing applications, where only limited observation horizons can be maintained.

Profiles allow extend UML vocabulary and the design patterns define a common vocabulary for software designers, therefore it is possible to use profile to define a pattern vocabulary in UML. If profiles are used to represent patterns then it is not required to define a special notation neither a particular CASE tool for patterns (UML tool is used). Three mechanisms are in the profiles: stereotypes, tag values and constraints. Stereotypes extend the UML vocabulary and it is possible to associate to it tag values and constraints. When these elements are introduced in models; patterns can be clearly visualized, software developers improve communication and establish a common vocabulary. Also profiles allow add information to the model to transform it to other models. OCL (Object Constraint Language) constraints are semantic restrictions added to UML elements. This work shows a way in which OCL constraints are used to define semantic restrictions over stereotypes included in a profile of pattern. The definition of OCL constraints for proxy design pattern is shown as an example of our proposal. An interaction between users and UML tool is proposed for solving the loss generality when OCL constrains are imposed.

We investigate here an approach to modelling the dynamic information requirements of a user performing a number of tasks, addressing both the provision and representation of information, viewing the information as being distributed across a set of resources. From knowledge of available resources at the user interface, and task information needs we can identify whether the system provides the user with adequate support for task execution. We look at how we can use tools to help reason about these issues, and illustrate their use through an example.We also consider a full range of analyses suggested using this approach which could potentially be supported by automated reasoning systems.

This paper describes a case-study, dealing with the application of the cognitive walkthrough as a meth od of evaluating an interface built for children. We perf ormed the walkthrough and tested the interface with children aged between 5 and 7 years old. Given our goals and the scope of this study, the cognitive walkthrough proved as a reliable source of indications about usability problems on an interface aimed at children.