Comparación entre cirugía asistida por navegación y cirugía convencional en el reemplazo total de rodilla

Introducción: El reemplazo total de rodilla es el tratamiento de elección en los estadios finales de la patología degenerativa articular; su duración depende, en gran medida, de la alineación, el posicionamiento y la estabilidad de la articulación. El objetivo de este estudio fue comparar el eje mecánico del miembro inferior medido por telemetría, después de un reemplazo total de rodilla asistido por navegación o con técnicas convencionales, realizado por el mismo cirujano y con la misma prótesis. Se evaluó también el grado de satisfacción de los pacientes sometidos a este procedimiento y su posible variación entre estas dos técnicas. Materiales y Métodos: Estudio retrospectivo, comparativo, observacional, descriptivo de 200 pacientes sometidos a un reemplazo total de rodilla, divididos en dos grupos: grupo A (100 pacientes) con prótesis Columbus® colocada con el sistema de navegación OrthoPilot® y grupo B (100 pacientes), con la misma prótesis colocada con técnica convencional. Se realizaron telemetrías posoperatorias para determinar y comparar el resultado en ambos grupos. También se comparó el grado de satisfacción con el procedimiento y el índice de masa corporal y su posible relación con los resultados. Resultados: Se obtuvieron mejores resultados en los reemplazos totales de cadera asistidos por navegación, con diferencias estadísticamente significativas tanto en la obtención del eje mecánico posoperatorio como en el grado de satisfacción con el procedimiento. Conclusión: Los reemplazos totales de rodilla primarios guiados por un sistema de navegación fueron más precisos para lograr la alineación final del miembro en un eje mecánico de 0°± 3°

Análisis de dependencias entre refactorings para solucionar code smells

Los code smells son síntomas en el código fuente que pueden revelar problemas de diseño. Para poder solucionar un smell deben aplicarse un conjunto de refactorings que permitan restructurar el sistema. Sin embargo, al aplicar un conjunto de refactorings en un orden determinado, pueden surgir problemas que impiden que éstos se apliquen. Por ejemplo, porque un refactoring que depende de una reestructuración realizada por otro refactoring que aún no fue aplicado, o porque un refactoring referencia un artefacto del sistema que fue modificado por un refactoring aplicado anteriormente. Por estos motivos, para aplicar un conjunto de refactorings, se deben analizar las dependencias que existen entre estos para poder establecer el orden de aplicación. En esta línea, este trabajo presenta una herramienta que identifica y soluciona los conflictos originados por dependencias entre refactorings para luego aplicar automáticamente los mismos. Los resultados, si bien son preliminares, indican que este enfoque permite identificar y solucionar un alto porcentaje de conflictos.Code smells are symptoms in the source code that can reveal design problems. To fix a smell, a set of refactorings must be applied that allow the restructure of the system. However, by applying a set of refactorings in a given order, problems can arise that prevent them from being applied. For example, a refactoring could depend on a restructuring made by another refactoring that was not yet applied, or a refactoring could reference a system artifact that was modified by a previously applied refactoring. For these reasons, to apply a set of refactorings, the developer must analyze the dependencies that exist between them to be able to establish the order of application. In this line, this work presents a tool that identifies and solves the conflicts originated by dependencies between refactorings and then automatically apply them. The results, although preliminary, indicate that this approach allows identifying and solving a high percentage of conflicts.Fil: Marcos, Claudia Andrea. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Vidal, Santiago Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentin

Estudios empíricos realizados con colecciones de proyectos software: un mapeo sistemático

Software projects are inputs in Evidence-Based Software Engineering, although they are selected without following a specific strategy, which decreases the generalization and replication of the results. One option is to use collections of existing projects, but these must have explicit construction and maintenance rules. The objective of this work was to perform a secondary study on software project selection strategies in empirical studies, and learn about: the rules considered, project characteristics, code metrics, extraction tools and statistical analyses employed. A systematic mapping was used to identify articles from January 2013 to December 2021. We selected 150 studies in which 67% used their own rules for project selection and 31% worked with existing collections, and the majority (80%) used Java projects. Furthermore, there was no evidence of a standardized framework for project selection for empirical studies in Software Engineering.Los proyectos software son insumos en la Ingeniería del Software Basada en Evidencias, aunque estos sean seleccionados sin seguir una estrategia específica, lo cual disminuye la generalización y replicación de los resultados. Una opción es usar colecciones de proyectos existentes, pero estas deben contar con reglas explícitas de construcción y mantenimiento. El objetivo de este trabajo fue realizar un estudio secundario sistematizado sobre las estrategias de selección de los proyectos software en estudios empíricos, y conocer: las reglas consideradas, las características de los proyectos, las métricas de código, las herramientas de extracción y los análisis estadísticos practicados. Se utilizó un mapeo sistemático para identificar artículos desde enero de 2013 a diciembre de 2021. Se seleccionaron 150 estudios de los cuales el 67% utilizó reglas propias para la selección de los proyectos y el 31% trabajó con colecciones existentes, y la mayoría (80%) empleó proyectos Java. Asimismo, no se encontraron evidencias de un marco estandarizado para la selección de proyectos para estudios empíricos en Ingeniería de Software.Sociedad Argentina de Informática e Investigación Operativ

A Systematic Mapping Study of Empirical Studies Performed with Collections of Software Projects

Contexto: los proyectos software son insumos comunes en los experimentos de la Ingeniería del Software, aunque estos muchas veces sean seleccionados sin seguir una estrategia específica, lo cual disminuye la representatividad y replicación de los resultados. Una opción es el uso de colecciones preservadas de proyectos software, pero estas deben ser vigentes y con reglas explícitas que aseguren su actualización a lo largo del tiempo. Objetivo: realizar un estudio secundario sistematizado sobre las estrategias de selección de los proyectos software en estudios empíricos para conocer las reglas tenidas en cuenta, el grado de uso de colecciones de proyectos, los metadatos extraídos y los análisis estadísticos posteriores realizados. Método: se utilizó un mapeo sistemático para identificar estudios publicados desde enero de 2013 a diciembre de 2020. Resultados: se identificaron 122 estudios de los cuales el 72% utilizó reglas propias para la selección de proyectos y un 27% usó colecciones de proyectos existentes. Asimismo, no se encontraron evidencias de un marco estandarizado para la selección de proyectos, ni la aplicación de métodos estadísticos que se relacionen con la estrategia de recolección de las muestras.Context: software projects are commonresources in Software Engineering experiments,although these are often selected without following a specific strategy, which reduces the representativeness and replication of the results. An option is the use of preserved collections of software projects, but these must be current, with explicit guidelines that guarante etheir updating over a long period of time. Goal: to carry out a systematic secondary study about the strategies to select software projects in empirical studies to discover the guidelines taken into account, the degree of use of project collections, the meta-data extracted and the subsequent statistical analysis conducted. Method: A systematic mapping study to identify studies published from January 2013 to December 2020. Results: 122 studies were identified, of which the 72% used their own guidelines for project selection and the 27% used existent project collections. Likewise, there was no evidence of a standardized framework for the project selection process, nor the application of statistical methods that relates with the sample collection strategy.Fil: Carruthers, Juan Andrés. Universidad Nacional del Nordeste. Facultad de Cs.exactas Naturales y Agrimensura. Departamento de Informatica; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Nordeste; ArgentinaFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Irrazábal, Emanuel Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Nordeste; Argentina. Universidad Nacional del Nordeste. Facultad de Cs.exactas Naturales y Agrimensura. Departamento de Informatica; Argentin

A Systematic Mapping Study of Empirical Studies Performed with Collections of Software Projects

Contexto: los proyectos software son insumos comunes en los experimentos de la Ingeniería del Software, aunque estos muchas veces sean seleccionados sin seguir una estrategia específica, lo cual disminuye la representatividad y replicación de los resultados. Una opción es el uso de colecciones preservadas de proyectos software, pero estas deben ser vigentes y con reglas explícitas que aseguren su actualización a lo largo del tiempo. Objetivo: realizar un estudio secundario sistematizado sobre las estrategias de selección de los proyectos software en estudios empíricos para conocer las reglas tenidas en cuenta, el grado de uso de colecciones de proyectos, los metadatos extraídos y los análisis estadísticos posteriores realizados. Método: se utilizó un mapeo sistemático para identificar estudios publicados desde enero de 2013 a diciembre de 2020. Resultados: se identificaron 122 estudios de los cuales el 72% utilizó reglas propias para la selección de proyectos y un 27% usó colecciones de proyectos existentes. Asimismo, no se encontraron evidencias de un marco estandarizado para la selección de proyectos, ni la aplicación de métodos estadísticos que se relacionen con la estrategia de recolección de las muestras.Context: software projects are commonresources in Software Engineering experiments,although these are often selected without following a specific strategy, which reduces the representativeness and replication of the results. An option is the use of preserved collections of software projects, but these must be current, with explicit guidelines that guarante etheir updating over a long period of time. Goal: to carry out a systematic secondary study about the strategies to select software projects in empirical studies to discover the guidelines taken into account, the degree of use of project collections, the meta-data extracted and the subsequent statistical analysis conducted. Method: A systematic mapping study to identify studies published from January 2013 to December 2020. Results: 122 studies were identified, of which the 72% used their own guidelines for project selection and the 27% used existent project collections. Likewise, there was no evidence of a standardized framework for the project selection process, nor the application of statistical methods that relates with the sample collection strategy.Fil: Carruthers, Juan Andrés. Universidad Nacional del Nordeste. Facultad de Cs.exactas Naturales y Agrimensura. Departamento de Informatica; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Nordeste; ArgentinaFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Irrazábal, Emanuel Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Nordeste; Argentina. Universidad Nacional del Nordeste. Facultad de Cs.exactas Naturales y Agrimensura. Departamento de Informatica; Argentin

Association Between Preexisting Versus Newly Identified Atrial Fibrillation and Outcomes of Patients With Acute Pulmonary Embolism

Background Atrial fibrillation (AF) may exist before or occur early in the course of pulmonary embolism (PE). We determined the PE outcomes based on the presence and timing of AF. Methods and Results Using the data from a multicenter PE registry, we identified 3 groups: (1) those with preexisting AF, (2) patients with new AF within 2 days from acute PE (incident AF), and (3) patients without AF. We assessed the 90-day and 1-year risk of mortality and stroke in patients with AF, compared with those without AF (reference group). Among 16 497 patients with PE, 792 had preexisting AF. These patients had increased odds of 90-day all-cause (odds ratio [OR], 2.81; 95% CI, 2.33-3.38) and PE-related mortality (OR, 2.38; 95% CI, 1.37-4.14) and increased 1-year hazard for ischemic stroke (hazard ratio, 5.48; 95% CI, 3.10-9.69) compared with those without AF. After multivariable adjustment, preexisting AF was associated with significantly increased odds of all-cause mortality (OR, 1.91; 95% CI, 1.57-2.32) but not PE-related mortality (OR, 1.50; 95% CI, 0.85-2.66). Among 16 497 patients with PE, 445 developed new incident AF within 2 days of acute PE. Incident AF was associated with increased odds of 90-day all-cause (OR, 2.28; 95% CI, 1.75-2.97) and PE-related (OR, 3.64; 95% CI, 2.01-6.59) mortality but not stroke. Findings were similar in multivariable analyses. Conclusions In patients with acute symptomatic PE, both preexisting AF and incident AF predict adverse clinical outcomes. The type of adverse outcomes may differ depending on the timing of AF onset.info:eu-repo/semantics/publishedVersio

An approach to prioritize code smells for refactoring

Code smells are a popular mechanism to find structural design problems in software systems. Consequently, several tools have emerged to support the detection of code smells. However, the number of smells returned by current tools usually exceeds the amount of problems that the developer can deal with, particularly when the effort available for performing refactorings is limited. Moreover, not all the code smells are equally relevant to the goals of the system or its health. This article presents a semi-automated approach that helps developers focus on the most critical problems of the system. We have developed a tool that suggests a ranking of code smells, based on a combination of three criteria, namely: past component modifications, important modifiability scenarios for the system, and relevance of the kind of smell. These criteria are complementary and enable our approach to assess the smells from different perspectives. Our approach has been evaluated in two case-studies, and the results show that the suggested code smells are useful to developers.Fil: Vidal, Santiago Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Marcos, Claudia Andrea. Universidad Nacional del Centro de la Provincia de Buenos Aires. Facultad de Ciencias Exactas. Instituto de Sistemas Tandil; Argentina. Provincia de Buenos Aires. Gobernación. Comisión de Investigaciones Científicas; ArgentinaFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentin

Over-exposed classes in Java: An empirical study

Java access modifiers regulate interactions among software components. In particular, class modifiers specify which classes from a component are publicly exposed and therefore belong to the component public interface. Restricting the accessibility as specified by a programmer is key to ensure a proper software modularity. It has been said that failing to do so is likely to produce maintenance problems, poor system quality, and architecture decay. However, how developers uses class access modifiers or how inadequate access modifiers affect software systems has not been investigated yet in the literature. In this work, we empirically analyze the use of class access modifiers across a collection of 15 Java libraries and 15 applications, totaling over 3.6M lines of code. We have found that an average of 25% of classes are over-exposed, i.e., classes defined with an accessibility that is broader than necessary. A number of code patterns involving over-exposed classes have been formalized, characterizing programmers' habits. Furthermore, we propose an Eclipse plugin to make component public interfaces match with the programmer's intent.Fil: Vidal, Santiago Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Bergel, Alexandre. Universidad de Chile; ChileFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Marcos, Claudia Andrea. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentina. Universidad Nacional del Centro de la Provincia de Buenos Aires. Facultad de Ciencias Exactas; Argentin

Understanding and addressing exhibitionism in Java empirical research about method accessibility

Information hiding is a positive consequence of properly defining component interfaces. Unfortunately, determining what should constitute a public interface remains difficult. We have analyzed over 3.6 million lines of Java open-source code and found that on the average, at least 20 % of defined methods are over-exposed, thus threatening public interfaces to unnecessary exposure. Such over-exposed methods may have their accessibility reduced to exactly reflect the method usage. We have identified three patterns in the source code to identify over-exposed methods. We also propose an Eclipse plugin to guide practitioners in identifying over-exposed methods and refactoring their applications. Our plugin has been successfully used to refactor a non-trivial application.Fil: Vidal, Santiago Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Bergel, Alexandre. Universidad de Chile; ChileFil: Marcos, Claudia Andrea. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentina. Provincia de Buenos Aires. Gobernación. Comisión de Investigaciones Científicas; ArgentinaFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentin

A tool to prioritize code smells in distributed development

A code smell is a symptom in the source code that helps to identify a design problem. Several tools for detecting and ranking code smells according to their criticality to the system have been developed. However, existing works assume a centralized development approach, which does not consider systems being developed in a distributed fashion. The main problem in a distributed group of developers is that a tool cannot always ensure a global vision of (smells of) the system, and thus inconsistencies among the rankings provided by each developer are likely to happen. These inconsistencies often cause unnecessary refactorings and might not focus the whole team on the critical smells system-wide. Along this line, this work proposes a multi-agent tool, called D-JSpIRIT, which helps individual developers to reach a consensus on their smell rankings by means of distributed optimization techniques.Fil: Vázquez, Hernán Ceferino. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Marcos, Claudia Andrea. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Vidal, Santiago Agustín. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; ArgentinaFil: Diaz Pace, Jorge Andres. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentin