Una propuesta de marco de trabajo orientado al dominio del procesamiento transaccional

La ingeniería de software establece que la construcción de programas debe ser encarado de la misma forma que los ingenieros construyen otros sistemas complejos. Los sistemas de procesamiento transaccional no son la excepción. Para lidiar con algunos de los desafíos de construir estas soluciones, se desarrolló una propuesta de marco de trabajo, que propone la construcción de una base de conceptos comunes, obtenidos del análisis de soluciones preexistentes, y de experiencias del equipo que desarrolla esta propuesta. Esta recolección de factores comunes se hace de forma iterativa, y se capitaliza en elementos del framework que aquí se introduce. Ese marco de trabajo tendrá como objetivos aumentar la reusabilidad, disminuir los costos de mantenimiento, y fomentar la comunicación entre los desarrolladores. Para tal fin, se pretende implementar una metodología MDD (DSM) que permita facilitar el uso del marco de trabajo a otros usuarios ajenos al desarrollo de esta propuesta. La implementación específica DSM será a través de un lenguaje de dominio específico que concentre en elementos de dominio, la experiencia concentrada en el framework.Eje: Ingeniería de Softwar

Modelo para el tratamiento de la deuda técnica orientado a la evolución de los componentes para que las aplicaciones sean sostenibles a largo plazo

La Deuda Técnica es un fenómeno habitual del proceso de construcción de software, la cual es reconocida como un conjunto de malas prácticas y decisiones incorrectas en la fase de construcción de software, aceptada generalmente como efecto colateral en proyectos de software donde puede existir presiones de cronograma y con entregas continuas de valor a corto plazo. Ciertos aspectos de este fenómeno son conocidos de forma general, lo que sigue sin conocerse en profundidad, es cómo la deuda técnica se manifiesta y afecta específicamente los procesos de software, y cómo las técnicas de desarrollo de software empleadas acomodan o mitigan la presencia de esta deuda (Holvitie et al., 2018). La deuda técnica ha ganado visibilidad en los últimos años debido al interés en los proyectos de software que usan marcos de desarrollo ágil, los cuales detallan la responsabilidad que tienen los equipos de desarrollo en producir código de calidad, y que en su afán de entregar software funcionando en el menor tiempo posible, renuncian a actividades relacionadas con la producción de código de calidad, como son, el uso de buenas prácticas de codificación, definiciones de diseños y arquitecturas incompletas, poca cobertura de pruebas y documentación, entre otros, que a largo plazo acumulan una gran cantidad de deuda técnica que se vuelve perjudicial para el éxito de los proyectos. Parte de este estudio es comprender los antecedentes, dimensiones, atributos y consecuencias de la deuda técnica, para así poder proponer un modelo de referencia para el tratamiento de la deuda técnica, y cómo puede éste ser adaptado como parte de un proceso de madurez similar a los existentes en desarrollo de software general. El entendimiento de las causas para lograr que las aplicaciones puedan ser sostenibles a largo plazo, será el principal enfoque para la selección de las principales técnicas para el tratamiento de la deuda técnica definidas en la literatura, las tecnologías y herramientas que serán útiles para registrar y hacer las mediciones de deuda técnica, especificar qué actividades y ejemplos claros de cómo deberían ser implementadas según el modelo por parte de los equipos de desarrollo, contribuyendo a reducir y gestionar la deuda técnica en las aplicaciones. El modelo propuesto debe proporcionar un enfoque útil para comprender y gestionar la deuda técnica con fines prácticos, que involucre futuras líneas de investigación.Technical Debt is a common phenomenon of the software construction process, the quality is recognized as a set of bad practices and incorrect decisions in the software construction phase, normally accepted as a side effect in software projects where there may be schedule difficulties and with continuous deliveries of short-term value. Certain aspects of this phenomenon are generally known, what remains unknown in depth, is how technical debt manifests and specifically affects software processes, and how the software development techniques used accommodate or mitigate the presence of this debt (Holvitie et al., 2018).Technical debt has gained visibility in recent years due to interest in software projects that use agile development frameworks, which detail the responsibility that development teams have in producing quality code, and that in their eagerness to deliver software functioning in the shortest possible time, they give up activities related to the production of quality code, such as the use of good coding practices, definitions of incomplete designs and architectures, little evidence and documentation coverage, among others, that over term accumulate a large amount of technical debt that becomes detrimental to the success of the projects. Part of this study is to understand the background, dimensions, attributes and consequences of technical debt, in order to propose a reference model for the treatment of technical debt, and how it can be adapted as part of a maturity process similar to those existing in general software development. Understanding the causes to ensure that applications can be sustainable in the long term will be the main approach for the selection of the main techniques for the treatment of technical debt defined in the literature, the technologies and tools that will be useful for recording and make the measurements of technical debt, specify what activities and clear examples of how they should be implemented according to the model by the development teams, contributing to reduce and manage the technical debt in the applications. The proposed model should provide a useful approach to understand and manage technical debt for practical purposes, which involves future lines of research.Magíster en Ingeniería de SoftwareMaestrí

Estrategias de Resolución del Code Smell Feature Envy

Los code smells son síntomas útiles para la identificación de problemas estructurales de un sistema que se relacionan con problemas de modificabilidad. Surgen por la utilización de malas prácticas al desarrollar un sistema. Para poder solucionar los code smells es necesario aplicar el refactoring que permitan mejorar aspectos de calidad como mantenibilidad, comprensibilidad y reusabilidad. El code smell Feature Envy puede ser considerado el síntoma más común relacionado con problemas de acoplamiento y cohesión. Es un método que parece más interesado en los datos de otra clase que en los de su propia clase. Este problema puede ser solucionado aplicando los refactorings Extract Method y Move Method. Sin embargo, la identificación de la mejor estrategia de resolución no siempre es sencilla dado que requiere de un análisis detallado de las diferentes alternativas. Por esta razón, en este trabajo se propone una estrategia de resolución del code smell Feature Envy la cuál propone al desarrollador diferentes alternativas de solución utilizando un algoritmo heurístico de manera tal que pueda analizar dichas posibilidades y utilizar la que considere más adecuada al proyectoSociedad Argentina de Informática e Investigación Operativ

Estrategias de Resolución del Code Smell Feature Envy

Los code smells son síntomas útiles para la identificación de problemas estructurales de un sistema que se relacionan con problemas de modificabilidad. Surgen por la utilización de malas prácticas al desarrollar un sistema. Para poder solucionar los code smells es necesario aplicar el refactoring que permitan mejorar aspectos de calidad como mantenibilidad, comprensibilidad y reusabilidad. El code smell Feature Envy puede ser considerado el síntoma más común relacionado con problemas de acoplamiento y cohesión. Es un método que parece más interesado en los datos de otra clase que en los de su propia clase. Este problema puede ser solucionado aplicando los refactorings Extract Method y Move Method. Sin embargo, la identificación de la mejor estrategia de resolución no siempre es sencilla dado que requiere de un análisis detallado de las diferentes alternativas. Por esta razón, en este trabajo se propone una estrategia de resolución del code smell Feature Envy la cuál propone al desarrollador diferentes alternativas de solución utilizando un algoritmo heurístico de manera tal que pueda analizar dichas posibilidades y utilizar la que considere más adecuada al proyectoSociedad Argentina de Informática e Investigación Operativ

Cobertura entre pruebas a distintos niveles para refactorizaciones más seguras

Esta tesis busca encontrar una práctica metodológica que permita definir distintos niveles de pruebas que operen como garantía de refactorizaciones seguras, independientemente del alcance de las mismas. Se enmarca en el tema general de refactoring, con elementos de Test Driven Development (TDD), utilizando las prácticas recomendadas en el marco de Behavior Driven Development (BDD) y de Acceptance Test Driven Development (ATDD). La práctica de refactoring descansa fuertemente en la existencia de pruebas unitarias automatizadas, que funcionan como red de seguridad que garantiza que el comportamiento de la aplicación no varía luego de una refactorización. Sin embargo, este simple enunciado no prevé que hay ocasiones en que las pruebas dejan de funcionar al realizar las refactorizaciones, con lo cual se pierde la sincronización entre código y pruebas, y la cualidad de red de seguridad de estas últimas. Esto es especialmente cierto ante refactorizaciones estructurales y rediseños macro. Por lo tanto, y dado que el uso de pruebas como red de contención es uno de los supuestos más fuertes de la práctica del refactoring, vamos a desarrollar, como objetivo de esta tesis, una práctica metodológica para permitir definir distintos niveles de pruebas que aseguren distintos tipos de refactorizaciones, validándola con un caso de estudio y apoyándonos en una herramienta automática desarrollada en el marco de este trabajo.Facultad de Informátic

Una evaluación experimental para comparar la calidad de un software aplicando o no TDD dentro del modelo cascada

El presente trabajo de investigación brinda un enfoque general de la aplicación de la técnica Test Driven Development (TDD), o Desarrollo Guiado por Pruebas, dentro de la metodología tradicional con enfoque Cascada, y cómo su implicancia proporciona resultados favorables durante el proceso de implementación y en consecuencia la mejora de la calidad del producto. La investigación se llevó a cabo mediante una evaluación experimental en donde se crearon cuatro (4) grupos de desarrollo, cada uno de ellos estaba conformado por once (11) estudiantes del octavo ciclo de la especialidad de Ingeniería Informática. El experimento consistió en que dos (2) grupos apliquen la técnica de TDD dentro de la metodología Cascada y los otros (2) grupos no la apliquen. La inclusión de la técnica TDD se llevó a cabo en las primeras fases del modelo Cascada (Definición de requerimientos y Diseño del sistema) a través de la definición de los Casos de Prueba (Test Cases) y mediante ellos se estableció la línea inicial para el comienzo de la implementación del código fuente del sistema a realizar. Mediante la aplicación de este experimento se logró obtener resultados estadísticos iniciales que confirman que la inclusión de la técnica TDD en el proceso de implementación y pruebas unitarias permite identificar una mayor cantidad de errores, lo cual se ve reflejado al final del proceso en un producto de mayor calidad. Finalmente, al concluir el proceso de desarrollo del software, se aplicó una encuesta para medir la percepción / intención de uso de los participantes respecto a las técnicas TDD y Cascada.Tesi

Estado del arte y tendencias en Test-Driven Development

Test-Driven Development, o TDD como se lo conoce más a menudo, surgió como una práctica de diseño de software orientado a objetos, basada en derivar el código de pruebas automatizadas escritas antes del mismo. Sin embargo, con el correr de los años, se ha ido ampliando su uso. Se ha utilizado para poner el énfasis en hacer pequeñas pruebas de unidad que garanticen la cohesión de las clases, así como en pruebas de integración que aseguren la calidad del diseño y la separación de incumbencias. Otros han querido enfatizar su adecuación como herramienta de especificación de requerimientos. Y en los últimos años se ha comenzado a avanzar con los conceptos de TDD hacia las pruebas de interacción a través de interfaces de usuario. Este trabajo pretende hacer una revisión del estado del arte de TDD y evaluar futuras tendencias, que inequívocamente se están dirigiendo a una integración de las distintas clases de TDD.Facultad de Informátic

Representación de la Evolución y Refactoring de Arquitecturas de Software mediante la Aplicación y Captura de Operaciones Arquitectónicas

La evolución de arquitecturas de software es consecuencia de cambios como la redefinición de requerimientos, o mejoras en la infraestructura/tecnología del sistema. Es necesario que la introducción de cambios arquitectónicos sea realizada de manera sistemática, a fin de evitar la erosión en el diseño arquitectónico y la pérdida de información vital para la comprensión del diseño obtenido. Los cambios aplicados y las decisiones tomadas deben ser documentados adecuadamente, para que se puedan recuperar posteriormente las soluciones aplicadas y conocer su impacto en la arquitectura. Se propone un modelo para representación del conocimiento durante la evolución de arquitecturas de software, basado en la aplicación de operaciones de evolución y refactoring. Las operaciones ejecutadas son capturadas junto con los elementos arquitectónicos sobre los que operaron, los resultados obtenidos, y los objetivos perseguidos, manteniendo así las trazas entre las diferentes versiones del modelo arquitectónico alcanzadas y la historia completa de su evolución.Software arquitectures evolution occurs as a consequence of changes, such us requiremens redefinition or infrastructure/technology improvements. The applying of architectural changes should be done in a systematic way, in order to avoid the design erosion and the lost of important information about the design process that is useful for understanding the obtained design. Applied changes and decisions made should be properly documented in order to make possible recovering them later and understanding their impact on the software architectures. In this work, a model for representing the generated and applied architectural knowledge during software architectures evolution processes is proposed, which it is based on evolution and refactoring operations. The executed operations are captured along with the architectural elements on which they operated, the resulting outcomes, and the pursued design goals. In this way, the approach keeps the traces among the several achieved versions of the software architecture model and the whole evolution history.Fil: Leone, Horacio Pascual. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); ArgentinaFil: Roldán, María Luciana. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); ArgentinaFil: Gonnet, Silvio Miguel. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); Argentin

Análisis y comparación de algoritmos de identificación de características aplicados a una familia de productos de software

El desarrollo de software es una tendencia hoy en día por lo que la cantidad de código que se ha generado en los últimos años ha aumentado significativamente. Adicionalmente, el aumento de demanda y la necesidad de reducir los tiempos de desarrollo generan problemas a corto y largo plazo que dificultan la mantenibilidad de cualquier proyecto. La reutilización de elementos de software (código fuente, modelos, entre otros), ha sido una práctica que se ha realizado a través de técnicas que no tienen en cuenta su soporte. Las líneas de productos de software (SPL) promueven la construcción de elementos que se puedan reutilizar y actualizar de acuerdo a las necesidades de manera organizada. En busca de la reutilización, existen técnicas extractivas que buscan componentes en proyectos legados o monolíticos, software que se creó teniendo en cuenta un objetivo específico. Existen varios casos de estudio, en donde se ha construido una SPL a partir de elementos que no buscaban ser reutilizados originalmente. Particularmente, ArgoUML SPL fue un proyecto creado en Java, el cual ha sido usado para verificar la efectividad de los algoritmos automáticos de análisis y extracción de características. Sin embargo, debido a la cantidad de variantes que existen en este caso de estudio, se hace evidente mostrar una comparación que sintetice y establezca un punto de referencia para la construcción de algoritmos de recuperación de características. Por tal motivo en este trabajo se realizó la construcción de una medida de comparación y se implementó una técnica que sirva como punto de referencia para futuras investigaciones utilizando dicha métrica unificada.Abstract: Nowadays, Software development is a trend, so the amount of code that has been generated in recent years has increased significantly. Additionally, the demand of software is also increasing, and the need to reduce the development time generates short and longterm problems that make difficult the maintenance of any project. The reuse of software elements (source code, models, among others), has been a practice that has been carried out through techniques that do not pay enough attention to the maintenance of the multiple projects. Software product lines (SPL) promote the construction of assets that can be reused and updated according to needs in a systematic manner. In search of reuse, there are instructive techniques that look for components in legacy or monolithic projects, software that was created with a specific objective in mind. There are several cases of study, where an SPL has been built from assets that did not seek to be reused originally. In particular, ArgoUML SPL was a project created in Java, which has been extensively used to test automatic techniques of identification and extraction of features. However, due to the number of variants that exist in this case study, it is evident to show a comparison that synthesizes and establishes a reference point for the construction of feature recovery algorithms. The main objective of this work is build a groundtruth to compare feature location algorithms and implement a technique which can be used as a reference to compare future researches.Maestrí

Generador de código de funcionalidades tipo crud en la mantenibilidad de software aplicado a sistemas de información empresariales

En el presente trabajo de investigación se realizó con el objetivo de demostrar que el desarrollo y la aplicación de un software generador de código tipo CRUD favorece la mantenibilidad de código aplicado a sistemas de información empresariales, por esta razón sustentaremos que, escribiendo código con una baja complejidad, componentes desacoplados, respetando las convenciones de nombres y líneas de comentarios descriptivos para los métodos podemos lograr un alto índice de mantenibilidad de software. Para el desarrollo de esta investigación se recolectó la información a través de un análisis de código minucioso, donde gracias al uso de herramientas de software y métricas de código se pudo establecer cuantitativamente que el proyecto de software desarrollado aumenta la facilidad para realizar pruebas unitarias y realizar cambios al código generado. Los resultados obtenidos demostraron que la facilidad para hacer pruebas unitarias mejoró sustancialmente, validándose un cambio de FPU >23 (pre-test) a FPU<=8.8 (post-test) y la facilidad para hacer cambios de la misma forma, validándose valores de FC>12000 (pre test) a valores de FC<4650 (post-test). Estos valores reflejaron que la Mantenibilidad mejoró significativamente obteniendo un incremento del Índice de Mantenibilidad desde un IM=82.43. Con base en lo mencionado, se llegó a la conclusión que utilizar un software que genere una arquitectura de código que respete los estándares de mantenibilidad favorece este criterio de calidad de manera significativa, pero ya depende del programador continuar bajo la línea de buenas prácticas al momento de realizar cualquier tipo de mantenimiento al software.In the present research work it was carried out with the objective of demonstrating that the development and application of a CRUD code generating software favors the maintainability of code applied to business information systems, for this reason we will support that, writing code with a low complexity, decoupled components, respecting the conventions of names and descriptive comment lines for the methods we can achieve a high index of software maintainability. For the development of this investigation, the information was collected through a thorough code analysis, where thanks to the use of software tools and code metrics it was quantitatively established that the software project developed increases the ease to perform unit tests and perform Changes to the generated code. The results showed that the ease of doing unit tests improved, validating a change from FPU> 23 (pre-test) to FPU <= 8.8 (post-test) and the facility to make changes in the same way, validating FC > 12000 (pretest) at FC<4650 (posttest). These values correspond to the Maintainability significantly improved obtaining an increase in the Maintainability Index from an IM = 82.43. Based on the aforementioned, it was concluded that using software that generates a code architecture that respects the maintainability standards favors this quality criterion significantly, but it is up to the programmer to continue under the line of good practices at the moment to perform any type of maintenance to the software