Object-Oriented Legacy System Trace-based Logic Testing

When reengineering legacy systems, it is crucial to assess if the legacy behavior has been preserved or how it changed due to the reengineering effort. Ideally if a legacy system is covered by tests, running the tests on the new version can identify potential differences or discrepancies. However, writing tests for an unknown and large system is difficult due to the lack of internal knowledge. It is especially difficult to bring the system to an appropriate state. Our solution is based on the acknowledgment that one of the few trustable piece of information available when approaching a legacy system is the running system itself. Our approach reifies the execution traces and uses logic programming to express tests on them. Thereby it eliminates the need to programatically bring the system in a particular state, and handles the test-writer a high-level abstraction mechanism to query the trace. The resulting system, called TESTLOG, was used on several real-world case studies to validate our claims.

Distribution Map

Understanding large software systems is a challenging task, and to support it many approaches have been developed. Often, the result of these approaches categorize existing entities into new groups or associates them with mutually exclusive properties. In this paper we present the Distribution Map as a generic technique to visualize and analyze this type of result. Our technique is based on the notion of focus, which shows whether a property is well-encapsulated or cross-cutting, and the notion of spread, which shows whether the property is present in several parts of the system. We present a basic visualization and complement it with measurements that quantify focus and spread. To validate our technique we show evidence of applying it on the result sets of different analysis approaches. As a conclusion we propose that the Distribution Map technique should belong to any reverse engineering toolkit.

Package Patterns for Visual Architecture Recovery

Recovering the architecture is the first step towards reengineering a software system. Many reverse engineering tools use top-down exploration as a way of providing a visual and interactive process for architecture recovery. During the exploration process, the user navigates through various views on the system by choosing from several exploration operations. Although some sequences of these operations lead to views which, from the architectural point of view, are mode relevant than others, current tools do not provide a way of predicting which exploration paths are worth taking and which are not. In this article we propose a set of package patterns which are used for augmenting the exploration process with in formation about the worthiness of the various exploration paths. The patterns are defined based on the internal package structure and on the relationships between the package and the other packages in the system. To validate our approach, we verify the relevance of the proposed patterns for real-world systems by analyzing their frequency of occurrence in six open-source software projects.

How Lisp systems look different

Many reverse engineering approaches have been developed to analyze software systems written in different languages like C/C++ or Java. These approaches typically rely on a meta-model, that is either specific for the language at hand or language independent (e.g. UML). However, one language that was hardly addressed is Lisp. While at first sight it can be accommodated by current language independent meta-models, Lisp has some unique features (e.g. macros, CLOS entities) that are crucial for reverse engineering Lisp systems. In this paper we propose a suite of new visualizations that reveal the special traits of the Lisp language and thus help in understanding complex Lisp systems. To validate our approach we apply them on several large Lisp case studies, and summarize our experience in terms of a series of recurring visual patterns that we have detected.

Test Blueprints - Exposing Side Effects in Execution Traces to Support Writing Unit Tests

Writing unit tests for legacy systems is a key maintenance task. When writing tests for object-oriented programs, objects need to be set up and the expected effects of executing the unit under test need to be verified. If developers lack internal knowledge of a system, the task of writing tests is non-trivial. To address this problem, we propose an approach that exposes side effects detected in example runs of the system and uses these side effects to guide the developer when writing tests. We introduce a visualization called Test Blueprint, through which we identify what the required fixture is and what assertions are needed to verify the correct behavior of a unit under test. The dynamic analysis technique that underlies our approach is based on both tracing method executions and on tracking the flow of objects at runtime. To demonstrate the usefulness of our approach we present results from two case studies.

Augmenting Static Source Views in IDEs with Dynamic Metrics

Mainstream IDEs such as Eclipse support developers in managing software projects mainly by offering static views of the source code. Such a static perspective neglects any information about runtime behavior. However, object-oriented programs heavily rely on polymorphism and late-binding, which makes them difficult to understand just based on their static structure. Developers thus resort to debuggers or profilers to study the system's dynamics. However, the information provided by these tools is volatile and hence cannot be exploited to ease the navigation of the source space. In this paper we present an approach to augment the static source perspective with dynamic metrics such as precise runtime type information, or memory and object allocation statistics. Dynamic metrics can leverage the understanding for the behavior and structure of a system. We rely on dynamic data gathering based on aspects to analyze running Java systems. By solving concrete use cases we illustrate how dynamic metrics directly available in the IDE are useful. We also comprehensively report on the efficiency of our approach to gather dynamic metrics.

Senseo: Enriching Eclipse's Static Source Views with Dynamic Metrics

Maintaining object-oriented systems that use inheritance and polymorphism is difficult, since runtime information, such as which methods are actually invoked at a call site, is not visible in the static source code. We have implemented Senseo, an Eclipse plugin enhancing Eclipse's static source views with various dynamic metrics, such as runtime types, the number of objects created, or the amount of memory allocated in particular methods.

Predicting dependencies using domain-based coupling

Software dependencies play a vital role in programme comprehension, change impact analysis and other software maintenance activities. Traditionally, these activities are supported by source code analysis; however, the source code is sometimes inaccessible or difficult to analyse, as in hybrid systems composed of source code in multiple languages using various paradigms (e.g. object-oriented programming and relational databases). Moreover, not all stakeholders have adequate knowledge to perform such analyses. For example, non-technical domain experts and consultants raise most maintenance requests; however, they cannot predict the cost and impact of the requested changes without the support of the developers. We propose a novel approach to predicting software dependencies by exploiting the coupling present in domain-level information. Our approach is independent of the software implementation; hence, it can be used to approximate architectural dependencies without access to the source code or the database. As such, it can be applied to hybrid systems with heterogeneous source code or legacy systems with missing source code. In addition, this approach is based solely on information visible and understandable to domain users; therefore, it can be efficiently used by domain experts without the support of software developers. We evaluate our approach with a case study on a large-scale enterprise system, in which we demonstrate how up to 65 of the source code dependencies and 77% of the database dependencies are predicted solely based on domain information.

Mining frequent bug-fix code changes

Detecting bugs as early as possible plays an important role in ensuring software quality before shipping. We argue that mining previous bug fixes can produce good knowledge about why bugs happen and how they are fixed. In this paper, we mine the change history of 717 open source projects to extract bug-fix patterns. We also manually inspect many of the bugs we found to get insights into the contexts and reasons behind those bugs. For instance, we found out that missing null checks and missing initializations are very recurrent and we believe that they can be automatically detected and fixed.

Overthrowing the Tyranny of Alphabetical Ordering in Documentation Systems

Software developers are often unsure of the exact name of the API method they need to use to invoke the desired behavior. Most state-of-the-art documentation browsers present API artefacts in alphabetical order. Albeit easy to implement, alphabetical order does not help much: if the developer knew the name of the required method, he could have just searched for it in the first place. In a context where multiple projects use the same API, and their source code is available, we can improve the API presentation by organizing the elements in the order in which they are more likely to be used by the developer. Usage frequency data for methods is gathered by analyzing other projects from the same ecosystem and this data is used then to improve tools. We present a preliminary study on the potential of this approach to improve the API presentation by reducing the time it takes to find the method that implements a given feature. We also briefly present our experience with two proof-of-concept tools implemented for Smalltalk and Java.

Microinformática en entornos profesionales : instalación, configuración, mantenimiento y reparación

Los sistemas microinformáticos se componen principalmente de hardware y software, con el paso del tiempo el hardware se degrada, se deteriora y en ocasiones se avería. El software evoluciona, requiere un mantenimiento, de actualización y en ocasiones falla teniendo que ser reparado o reinstalado. A nivel hardware se analizan los principales componentes que integran y que son comunes en gran parte estos sistemas, tanto en equipos de sobre mesa como portátiles, independientes del sistema operativo, además de los principales periféricos, también se analizan y recomiendan algunas herramientas necesarias para realizar el montaje, mantenimiento y reparación de estos equipos. Los principales componentes hardware internos son la placa base, memoria RAM, procesador, disco duro, carcasa, fuente de alimentación y tarjeta gráfica. Los periféricos más destacados son el monitor, teclado, ratón, impresora y escáner. Se ha incluido un apartado donde se detallan los distintos tipos de BIOS y los principales parámetros de configuración. Para todos estos componentes, tanto internos como periféricos, se ha realizado un análisis de las características que ofrecen y los detalles en los que se debe prestar especial atención en el momento de seleccionar uno frente a otro. En los casos que existen diferentes tecnologías se ha hecho una comparativa entre ambas, destacando las ventajas y los inconvenientes de unas frente a otras para que sea el usuario final quien decida cual se ajusta mejor a sus necesidades en función de las prestaciones y el coste. Un ejemplo son las impresoras de inyección de tinta frente a las laser o los discos duros mecánicos en comparación con y los discos de estado sólido (SSD). Todos estos componentes están relacionados, interconectados y dependen unos de otros, se ha dedicado un capítulo exclusivamente para estudiar cómo se ensamblan estos componentes, resaltando los principales fallos que se suelen cometer o producir y se han indicado unas serie tareas de mantenimiento preventivo que se pueden realizar para prolongar la vida útil del equipo y evitar averías por mal uso. Los mantenimientos se pueden clasificar como predictivo, perfectivo, adaptativo, preventivo y correctivo. Se ha puesto el foco principalmente en dos tipos de mantenimiento, el preventivo descrito anteriormente y en el correctivo, tanto software como hardware. El mantenimiento correctivo está enfocado al análisis, localización, diagnóstico y reparación de fallos y averías hardware y software. Se describen los principales fallos que se producen en cada componente, cómo se manifiestan o qué síntomas presentan para poder realizar pruebas específicas que diagnostiquen y acoten el fallo. En los casos que es posible la reparación se detallan las instrucciones a seguir, en otro caso se recomienda la sustitución de la pieza o componente. Se ha incluido un apartado dedicado a la virtualización, una tecnología en auge que resulta muy útil para realizar pruebas de software, reduciendo tiempos y costes en las pruebas. Otro aspecto interesante de la virtualización es que se utiliza para montar diferentes servidores virtuales sobre un único servidor físico, lo cual representa un importante ahorro en hardware y costes de mantenimiento, como por ejemplo el consumo eléctrico. A nivel software se realiza un estudio detallado de los principales problemas de seguridad y vulnerabilidades a los que está expuesto un sistema microinformático enumerando y describiendo el comportamiento de los distintos tipos de elementos maliciosos que pueden infectar un equipo, las precauciones que se deben tomar para minimizar los riesgos y las utilidades que se pueden ejecutar para prevenir o limpiar un equipo en caso de infección. Los mantenimientos y asistencias técnicas, en especial las de tipo software, no siempre precisan de la atención presencial de un técnico cualificado, por ello se ha dedicado un capítulo a las herramientas de asistencia remota que se pueden utilizar en este ámbito. Se describen algunas de las más populares y utilizadas en el mercado, su funcionamiento, características y requerimientos. De esta forma el usuario puede ser atendido de una forma rápida, minimizando los tiempos de respuesta y reduciendo los costes. ABSTRACT Microcomputer systems are basically made up of pieces of hardware and software, as time pass, there’s a degradation of the hardware pieces and sometimes failures of them. The software evolves, new versions appears and requires maintenance, upgrades and sometimes also fails having to be repaired or reinstalled. The most important hardware components in a microcomputer system are analyzed in this document for a laptop or a desktop, with independency of the operating system they run. In addition to this, the main peripherals and devices are also analyzed and a recommendation about the most proper tools necessary for maintenance and repair this kind of equipment is given as well. The main internal hardware components are: motherboard, RAM memory, microprocessor, hard drive, housing box, power supply and graphics card. The most important peripherals are: monitor, keyboard, mouse, printer and scanner. A section has been also included where different types of BIOS and main settings are listed with the basic setup parameters in each case. For all these internal components and peripherals, an analysis of their features has been done. Also an indication of the details in which special attention must be payed when choosing more than one at the same time is given. In those cases where different technologies are available, a comparison among them has been done, highlighting the advantages and disadvantages of selecting one or another to guide the end user to decide which one best fits his needs in terms of performance and costs. As an example, the inkjet vs the laser printers technologies has been faced, or also the mechanical hard disks vs the new solid state drives (SSD). All these components are interconnected and are dependent one to each other, a special chapter has been included in order to study how they must be assembled, emphasizing the most often mistakes and faults that can appear during that process, indicating different tasks that can be done as preventive maintenance to enlarge the life of the equipment and to prevent damage because of a wrong use. The different maintenances can be classified as: predictive, perfective, adaptive, preventive and corrective. The main focus is on the preventive maintains, described above, and in the corrective one, in software and hardware. Corrective maintenance is focused on the analysis, localization, diagnosis and repair of hardware and software failures and breakdowns. The most typical failures that can occur are described, also how they can be detected or the specific symptoms of each one in order to apply different technics or specific tests to diagnose and delimit the failure. In those cases where the reparation is possible, instructions to do so are given, otherwise, the replacement of the component is recommended. A complete section about virtualization has also been included. Virtualization is a state of the art technology that is very useful especially for testing software purposes, reducing time and costs during the tests. Another interesting aspect of virtualization is the possibility to have different virtual servers on a single physical server, which represents a significant savings in hardware inversion and maintenance costs, such as electricity consumption. In the software area, a detailed study has been done about security problems and vulnerabilities a microcomputer system is exposed, listing and describing the behavior of different types of malicious elements that can infect a computer, the precautions to be taken to minimize the risks and the tools that can be used to prevent or clean a computer system in case of infection. The software maintenance and technical assistance not always requires the physical presence of a qualified technician to solve the possible problems, that’s why a complete chapter about the remote support tools that can be used to do so has been also included. Some of the most popular ones used in the market are described with their characteristics and requirements. Using this kind of technology, final users can be served quickly, minimizing response times and reducing costs.

Year 2000 computing crisis : potential for widespread disruption calls for strong leadership and partnerships : report to Congressional requesters /

"B-279427"--P. 1.