24 research outputs found

    Are Forward Designed or Reverse-Engineered UML Diagrams More Helpful for Code Maintenance?: A Controlled Experiment

    Get PDF
    Context: UML has been the de facto standard notation for modeling object-oriented software systems since its appearance in 1997. UML diagrams are important for maintainers of a system, especially when the software was developed by a different team. These diagrams of the system are not always available, however, and are commonly recovered using Reverse Engineering (RE) techniques. When obtained through RE, UML diagrams have a high level of detail as compared to those developed in the forward design activity. Method: In this paper we report on a comparison of the attitude and performance of maintainers when using these two kinds of diagrams during the maintenance of source code. Our findings were obtained by carrying out a controlled experiment with 40 students of a Master’s degree in Computer Science. Results: The results show a preference for forward design diagrams but do not display significant differences in task performance. The post-experiment survey results have led us to conclude that the subjects did not consider RE diagrams helpful; they found them difficult to understand, particularly the sequence diagrams. In the case of forward design diagrams, subjects considered sequence diagrams as useful, but they did not really employ them. Conclusions: Based on our findings, as regards performance of maintainers, there are no objective results which favor the use of one of these types of diagram in particular, i.e., UML diagrams which come from forwards design, on the one hand, and diagrams obtained from RE, on the other. Subjective opinions do, however, lead us to recommend the use of diagrams created during design. Nevertheless, we realize that the results should be considered as preliminary ones; further replications of this experiment are planned, using students and professionals, the aim being to obtain more conclusive results.Ministerio de Economía y Competitividad TIN2012-37493-C03-0

    UML consistency rules: a systematic mapping study

    Get PDF
    Context: The Unified Modeling Language (UML), with its 14 different diagram types, is the de-facto standard tool for objectoriented modeling and documentation. Since the various UML diagrams describe different aspects of one, and only one, software under development, they are not independent but strongly depend on each other in many ways. In other words, the UML diagrams describing a software must be consistent. Inconsistencies between these diagrams may be a source of the considerable increase of faults in software systems. It is therefore paramount that these inconsistencies be detected, ana

    Revisión sistemática sobre el aseguramiento de la calidad de requisitos

    Get PDF
    La especificación de requisitos es un artefacto software crucial en el desarrollo de software y su calidad puede tener gran influencia sobre el producto software finalmente implementado, y más aún en un entorno de desarrollo global de software (DGS). Por ello es sumamente importante evaluar/asegurar la calidad de las especificaciones de requisitos. El objetivo de este informe es presentar una revisión sistemática de la literatura (RSL) con el fin de conocer las propuestas existentes sobre como evaluar y/o asegurar la calidad de los requisitos de productos software. La búsqueda de artículos se ha hecho en el periodo comprendido entre el 01/01/1990 y el 30/09/2010 en tres fuentes de búsquedas electrónicas (SCOPUS, ACM y Science Direct). Se han obtenido 67 estudios primarios, clasificado según las siguientes dimensiones: tipo de propuesta, característica de calidad, tipo de artefacto, tipo de software, método de validación, tipo de soporte. Como conclusión podemos decir que si bien todas las propuestas coinciden en la necesidad imperiosa de obtener especificaciones software de calidad debido a que tienen gran impacto económico y en la calidad de los productos software, no existen técnicas de evaluación/aseguramiento de la calidad de los requisitos ampliamente difundidas en la industria, y menos aún en entornos de DGS. Para contribuir a subsanar esta carencia creemos conveniente la utilización métodos empíricos que permitan validar la efectividad de las técnicas propuestas en entornos industriales. Lo que sí parece estar más claro es cuales son las características de calidad más relevantes, ellas son: completitud, consistencia, validación, corrección, no-ambigüedad y entendibilidad.Sociedad Argentina de Informática e Investigación Operativ

    UML consistency rules: a systematic mapping study

    No full text
    Context: The Unified Modeling Language (UML), with its 14 different diagram types, is the de-facto standard modeling language for object-oriented modeling and documentation. Since the various UML diagrams describe different aspects of one, and only one, software under development, they are not independent but strongly depend on each other in many ways. In other words, the UML diagrams describing a software product must be consistent. Inconsistencies between these diagrams may be a source of faults in software systems. It is therefore paramount that these inconsistencies be detected, analyzed and hopefully fixed. Objective: The aim of this article is to deliver a comprehensive summary of UML consistency rules as they are described in the literature to date to obtain an extensive and detailed overview of the current research in this area. Method: We performed a Systematic Mapping Study by following well-known guidelines. We selected 95 primary studies from a search with seven search engines performed in December 2012. Results: Different results are worth mentioning. First it appears that researchers tend to discuss very similar consistency rules, over and over again. Most rules are horizontal (98.10%) and syntactic (88.21%). The most used diagrams are the class diagram (71.58%), the sequence diagram (47.37%) and the state machine diagram (42.11%). Conclusion: The fact that many rules are duplicated in primary studies confirms the need for a well-accepted list of consistency rules. This paper is a first step in this direction. Results indicate that much more work is needed to develop consistency rules for all 14 UML diagrams, in all dimensions of consistency (e.g., semantic and syntactic on the one hand, horizontal, vertical and evolution on the other hand). Copyright 2014 ACM

    Empirical studies concerning the maintenance of UML diagrams and their use in the maintenance of code: A systematic mapping study

    No full text
    Context: The Unified Modelling Language (UML) has, after ten years, become established as the de facto standard for the modelling of object-oriented software systems. It is therefore relevant to investigate whether its use is important as regards the costs involved in its implantation in industry being worthwhile. Method: We have carried out a systematic mapping study to collect the empirical studies published in order to discover "What is the current existing empirical evidence with regard to the use of UML diagrams in source code maintenance and the maintenance of the UML diagrams themselves? Results: We found 38 papers, which contained 63 experiments and 3 case studies. Conclusion: Although there is common belief that the use of UML is beneficial for source code maintenance, since the quality of the modifications is greater when UML diagrams are available, only 3 papers concerning this issue have been published. Most research (60 empirical studies) concerns the maintainability and comprehensibility of the UML diagrams themselves which form part of the system\u27s documentation, since it is assumed that they may influence source code maintainability, although this has not been empirically validated. Moreover, the generalizability of the majority of the experiments is questionable given the material, tasks and subjects used. There is thus a need for more experiments and case studies to be performed in industrial contexts, i.e., with real systems and using maintenance tasks conducted by practitioners under real conditions that truly show the utility of UML diagrams in maintaining code, and that the fact that a diagram is more comprehensible or modifiable influences the maintainability of the code itself. This utility should also be studied from the viewpoint of cost and productivity, and the consistent and simultaneous maintenance of diagrams and code must also be considered in future empirical studies. \ua9 2013 Elsevier B.V. All rights reserved

    A systematic identification of consistency rules for UML diagrams

    No full text
    UML diagrams describe different views of one software. These diagrams strongly depend on each other and must therefore be consistent with one another, since inconsistencies between diagrams may be a source of faults during software development activities that rely on these diagrams. It is therefore paramount that consistency rules be defined and that inconsistencies be detected, analyzed and fixed. The relevant literature shows that authors typically define their own consistency rules, sometimes defining the same rules and sometimes defining rules that are already in the UML standard. The reason might be that no consolidated set of rules that are relevant by authors can be found to date. The aim of our research is to provide an up to date, consolidated set of UML consistency rules and obtain a detailed overview of the current research in this area. We therefore followed a systematic procedure in order to collect from literature up to Mar

    Does the level of detail of UML diagrams affect the maintainability of source code? A family of experiments

    No full text
    Although the UML is considered to be the de facto standard notation with which to model software, there is still resistance to model-based development. UML modeling is perceived to be expensive and not necessarily cost-effective. It is therefore important to collect empirical evidence concerning the conditions under which the use of UML makes a practical difference. The focus of this paper is to investigate whether and how the Level of Detail (LoD) of UML diagrams impacts on the performance of maintenance tasks in a model-centric approach. A family of experiments consisting of one controlled experiment and three replications has therefore been carried out with 81 students with different abilities and levels of experience from 3 countries (The Netherlands, Spain, and Italy). The analysis of the results of the experiments indicates that there is no strong statistical evidence as to the influence of different LoDs. The analysis suggests a slight tendency toward better results when using low LoD UML diagrams, especially if used for the modification of the source code, while a high LoD would appear to be helpful in understanding the system. The participants in our study also favored low LoD diagrams because they were perceived as easier to read. Although the participants expressed a preference for low LoD diagrams, no statistically significant conclusions can be drawn from the set of experiments. One important finding attained from this family of experiments was that the participants minimized or avoided the use of UML diagrams, regardless of their LoD. This effect was probably the result of using small software systems from well-known domains as experimental materials

    On the use of UML documentation in software maintenance: Results from a survey in industry

    No full text
    This paper presents the findings of a survey on the use of UML in software maintenance, carried out with 178 professionals working on software maintenance projects in 12 different countries. As part of long-term research we are carrying out to investigate the benefits of using UML in software maintenance, the main objectives of this survey are: 1) to explore whether UML diagrams are being used in software industry maintenance projects; 2) to see what UML diagrams are the most effective for software maintenance; 3) to find out what the perceived benefits of using UML diagrams are; and 4) to contextualize the kind of companies that use UML documentation in software maintenance. Some complementary results based on the way the documentation is used (whether it is UML-based or not) during software maintenance are also presented
    corecore