Visualization of Practices and Metrics (Workpackage 1.2)

Measuring applications is a challenge and one of the goal of the Squale project is to propose a sound quality model. Now presenting the results of such analysis is also a challenge since it is complex to output and present to the user for the following rea- sons: first a lot of data should be presented and at different audience. Second displaying information is one aspect another one is navigating the information. Finally it is im- portant not to overwhelm the users with too much visualizations. This workpackage presents a state of the art in terms of software visualization approaches that are specif- ically designed to display metrics. In addition it sets up the context for the application of such visualization to practices

Analysis of Existing Approaches to Constructing Component-based Systems Directly from Natural Language Requirements

System development generally starts with Requirements Engineering (RE) process. Based on requirements, system analysts produce the requirements documents and analyze them in order to produce design documents. These artefacts will be inputs to the later stages in the system development. It is argued that during the transition between these stages, considering many other various factors, information might be missed out or misinterpreted along the way. Hence, a better transition in the development cycle is required. This paper outlines and provides an analysis of the existing approaches in the literature on constructing systems from natural language requirements (NLR) as to provide the motivation of a new approach to constructing component-based system from NLR

Detección de defectos de diseño mediante métricas de código

La identificación de defectos de diseño en entidades de código es una de las tareas del proceso de mantenimiento del software que sirve para evaluar la calidad de un sistema. Un defecto de diseño describe una situación que sugiere un problema potencial en la estructura del software. La intención de diseño de la entidad, que puede ser expresada como estereotipos de clasificadores estándar de UML, proporciona una fuente de información utilizada en algunas definiciones textuales de defectos. En las entidades de código de un sistema software orientado a objetos la información de estereotipos UML no suele estar disponible explícitamente, aunque los diseñadores y programadores la hayan tenido en cuenta en sus soluciones. En la práctica de la automatización de detección de defectos de diseño, esta información es obviada a pesar de su posible utilidad en el proceso de identificación de defectos. Actualmente existen métodos de identificación del defecto de diseño GodClass basados en métricas de código. Incluso existen herramientas que lo automatizan, como InCode y JDeodorant, ambas avaladas con importantes publicaciones de investigación, en las que esta información no se tiene en cuenta. En esta tesis proponemos utilizar técnicas de aprendizaje supervisado basado en clasificadores de tipo árbol de decisión, para modelar el problema de la detección de defectos de diseño como una clasificación de entidades de código ``con defecto'' o ``sin defecto''. La clasificación inicial en la fase de entrenamiento se puede obtener a partir de los métodos actuales. Este trabajo presenta varios casos de estudio empirimentales para evaluar cómo influye la información relativa a la naturaleza de diseño de la entidad en la detección de tres defectos (GodClass, Feature Envy y Data Class) para distintos clasificadores. La evaluación consiste en comparar de medidas de rendimiento del clasificador obtenidas en la fase de entrenamiento (Recuperación, Precisión y F-Measure). Las resultados experimentales avalan la validez de considerar la naturaleza de diseño de la entidad en los métodos de identificación de defectos de código. Finalmente, como trasferencia del conocimiento de los resultados de investigación, en la tesis se proponen prototipos de herramientas software de detección de defectos de diseño que incluyen la naturaleza de diseñoDepartamento de Informátic

Towards automated restructuring of object oriented systems

The work introduces a method for diagnosing design flaws in object oriented systems, and finding meaningful refactorings to remove such flaws. The method is based on pairing up a structural pattern that is considered pathological (e.g. a code smell or anti-pattern) with a so called design context. The design context describes the design semantics associated to the pathological structure, and the desired strategic closure for that fragment. The process is tool supported and largely automated

A review of software change impact analysis

Change impact analysis is required for constantly evolving systems to support the comprehension, implementation, and evaluation of changes. A lot of research effort has been spent on this subject over the last twenty years, and many approaches were published likewise. However, there has not been an extensive attempt made to summarize and review published approaches as a base for further research in the area. Therefore, we present the results of a comprehensive investigation of software change impact analysis, which is based on a literature review and a taxonomy for impact analysis. The contribution of this review is threefold. First, approaches proposed for impact analysis are explained regarding their motivation and methodology. They are further classified according to the criteria of the taxonomy to enable the comparison and evaluation of approaches proposed in literature. We perform an evaluation of our taxonomy regarding the coverage of its classification criteria in studied literature, which is the second contribution. Last, we address and discuss yet unsolved problems, research areas, and challenges of impact analysis, which were discovered by our review to illustrate possible directions for further research

Java Smell Detector

“Code Smell” or “Bad Smell”, at the very least, is an indicator of badly written code and is often indicative of deeper problems in software design. In layman terms, it signals flaws in the core foundation or architecture of the software that can cause any number of more serious problems – from usability and runtime performance to supportability and enhancement. These problems can mostly be prevented by the systematic refactoring of the code. Refactoring is the process (and according to some, an ‘art’) of making incremental changes to existing source code to improve its nonfunctional attributes, without modifying its external functional behavior. Code smells are symptoms of deep-rooted problems in design, which, in most common cases, inhibit the understandability of the system for present and future programmers, hence rendering the program un-maintainable. The later these problems are identified, the costlier they are to correct as it is much harder to refactor a system in production and regression. Issues caused by refactoring can spiral out of control in advanced stages of the software development life cycle. So far, identification of these code smells has been thought of as an intuitive art rather than an exact science, as there are very few empirical measures or methodologies for doing so.In this project, I will examine each of the 22 code smells identified in prior research. I will implement Java Smell Detector (JSD), which will follow a scientific approach to detect five of these 22 code smells. JSD will give suggestions to refactor the code for all five of these smells. Further, the tool will provide an interactive process to refactor two of these cases; while for the rest, it will suggest an ideal refactoring technique that would need to be applied manually. I will be using Java code written by students of San Jose State University (SJSU) as test data for JSD and will compare its output against the code smells identified by the graduate students

Evolution of batch-oriented COBOL systems into object-oriented systems through unified modelling language.

Throughout the world, there are many legacy systems that fulfil critical business functions but often require new functionality to comply with new business rules or require redeployment to another platform. Legacy systems vary tremendously in size, functionality, type (such as batch-oriented or real-time), programming language source code, and many other factors. Furthermore, many of these legacy systems have missing or obsolete documentation which makes it difficult for developers to re-develop the system to meet any new functionality. Moreover, the high cost of whole scale redevelopment and high switchover costs preclude any replacement systems for these legacy systems. Reengineering is often proposed as a solution to this dilemma of high re-development and switchover costs. However, reengineering a legacy system often entails restructuring and re-documenting a system. Once these restructuring and re-documentation processes have been completed, the developers are better able to redevelop the parts of the systems that are required to meet any new functionality. This thesis introduces a number of methods to restructure a procedurally-structured, batch-oriented COBOL system into an object-oriented, event-driven system through the use of an intermediate mathematical language, the Wide Spectrum Language (WSL), using system source code as the only documentation artefact. This restructuring process is accomplished through the application of several algorithms of object identification, independent task evaluation, and event identification that are provided in the thesis. Once these transformations are complete, method(s) are specified to extract a series of UML diagrams from this code in order to provide documentation of this system. This thesis outlines which of the UML diagrams, as specified in the UML Specifications version 1.5, can be extracted using the specified methods and under what conditions this extraction, using system source code only, can occur in a batch-oriented system. These UML diagrams are first expressed through a WSL-UML notation; a notation which follows the semantics and structure of UML Specifications version 1.5 in order to ensure compatibility with UML but is written as an extension of WSL in order to enable WSL to represent abstract modelling concepts and diagrams. This WSL-UML notation is then imported into a visual UML diagramming tool for the generation of UML diagrams to represent this system. The variety of legacy systems precludes any universal approach to reengineering. Even if a legacy system shares a common programming language, such as COBOL, the large number of COBOL constructs and the huge number of possible dialects prevents any universal translator of the original program code to another. It is hoped that by focusing on one particular type of legacy system with constraints, in this case a batch-oriented COBOL system with its source code its only surviving artefact, and by providing validated algorithms to restructure and re-document these legacy systems in the Unified Modelling Language, an industry system modelling standard, and by determining which of these Unified Modelling Language can be extracted practically from such a system, some of the parameters and uncertainties, such as program understanding of an undocumented system, in reengineering this type of system can be reduced

Software architecture: styles and representational schemes

Software architecture is being widely used today to describe a very high-level design methodology of large software systems. Software architecture represents the overall structure of a system in an abstract, structured manner. A good architectural representation scheme holds the key to the effectiveness of a software architecture description and usage. In this work we look at architectural styles and architectural representation schemes. We propound the idea that the layered architectural model is a suitable candidate for a generalized architectural style and that it can cater to many different problem domains, other than the message-passing systems it has traditionally been used to model. We propose some rules by which the layered architectural style can be improved and modified in order to be able to model a wider problem domain. Then we evaluate different methods of architectural representations that have been used to model software architecture and analyze their strengths and shortcomings. We propose the use of a modified data flow diagram architecture representation scheme. This scheme is called AND-OR DFD method and is introduced and developed in this thesis. The main concept introduced here is a combination of components to form action groups to support multiple workflows and the relationships among them, without significant increase in the architectural complexity. Finally, we look at UML as a prospect for a generalized architecture description language and discuss its merits and demerits with examples

Refactorización sobre Programación Genérica en Lenguajes Orientados a Objetos

En el desarrollo del software, éste se degrada produciéndose la entropía software. Una de las labores fundamentales para su eliminación, es el mantenimiento perfectivo, y en particular, la refactorización. La independencia del lenguaje en la definición e implementación de refactorizaciones, así como la programación genérica en refactorización son dos importantes líneas abiertas de investigación en este campo. Con el objetivo de lograr cierta independencia en su definición e implementación se propone un metamodelo para la definición de los conceptos básicos y una plantilla para su definición, junto con un modelo de caracterización y proceso. Posteriormente se describe un nuevo catálogo de refactorizaciones en genericidad y se propone una arquitectura basada en frameworks. Finalmente se valida la solución sobre el lenguaje Java, construyendo un prototipo. En resumen, se aporta un nuevo enfoque a la hora de abordar las refactorizaciones, mejorando algunas de las deficiencias detectadasDepartamento de Informátic

Investigating the Effects of Design Quality in OSS Projects

Software systems are becoming an essential part of the lives of both individuals and organizations, and as a consequence, these systems are getting bigger and more complex. Because of this, the tasks of maintaining the quality in these complex software systems are becoming increasingly difficult. Furthermore, these systems are subject to constant pressure to add modifications, implementing new features, or regular bug fixing. Due to an often-strict release schedule, developers may not get the chance to design and implement ideal solutions. This can lead to decay in software design and the growth of technical debt, which negatively impacts the overall quality of the software. Design quality plays a vital role in maintaining the quality of software systems. In the past, several studies have shown the impact of design quality on different quality attributes such as bug density, productivity, and maintenance. Researchers also proposed several tools and techniques to improve design quality. Despite efforts by the research community in past years, there are still gaps in our understanding of how does design quality evolves in OSS projects, how projects manage design quality and how does design quality impacts the long-term health of the projects. This thesis proposes a number of large-scale empirical investigations aiming to understand the gaps. In the first part of this thesis, we investigate the evolution of design quality in OSS projects. Researchers used different metrics to measure the project’s design quality. In this thesis, we investigated two different design quality metrics. The first one is code smells, which are the result of poor design or implementation choices. And the second one is entropy, provides an understanding of design quality in terms of flexibility during the enhancement of its functionality. Our results show that design issues build up and design quality (measured by code smells and entropy) degrades over time. As the project grows older and larger, design issues are fixed less and, as a consequence, build up. In the second part, we investigate how OSS projects manage design quality. As design discussion is the primary mechanism for OSS projects to debate, make and document design decisions, we investigated how developers discuss design in the community, how they evolve along with design quality, and what effect they have on the design quality. Our results show that: I) Regardless of different communication channels used for discussion, 89:51% of all design discussions occur in the project mailing list, II) the average number of design discussions decrease; design quality degrade, as the project evolves, and III) the correlation between design discussions and design quality is small. In the third part, we investigate how does design quality impacts day to day activity (such as code merging) as well as long term health of the projects. We find that code with design issues (code smells) are more likely to be involved in merge conflicts. Our results also show that both code smells and entropy have an impact on the long-term health of the project. In this thesis, we use bug-proneness of the codebase as the measurement of the project’s long-term health