Automatización de un proceso de refactorización para la separación de concerns

La separación de concerns es una problemática importante de la ingeniería de software que influye en la modificabilidad de los sistemas. Si bien se han presentado prácticas arquitecturales que buscan solucionar esta problemática, existen concerns que son ortogonales a los módulos de un sistema (llamados crosscutting concerns) y no pueden ser modularizados por estas prácticas o por paradigmas de programación como el orientado a objetos. Con el objetivo de proveer mejores mecanismos de separación de concerns ha surgido la Programación Orientada a Aspectos (POA) la cual encapsula en un nuevo componente, llamado aspecto, los crosscutting concerns. Por esta razón, con el objetivo de aprovechar los beneficios de la POA ha surgido la necesidad de migrar los sistemas legados orientados a objetos a la orientación a aspectos. En este trabajo se propone la utilización de modelos de Markov con el fin de determinar el orden en el cual el código orientado a objetos debe ser migrado y para identificar las reestructuraciones a ser aplicadas durante el proceso de migración.Sociedad Argentina de Informática e Investigación Operativ

Un enfoque para automatizar la refactorización de casos de uso

Llevar a cabo las actividades de captura y modelamiento de requerimientos no es una tarea sencilla. Ésta requiere realizar un análisis profundo de las necesidades de los clientes y demanda cierto grado de experiencia de los analistas. Para comunicar satisfactoriamente los requerimientos, se deben aprovechar los instrumentos provistos por las técnicas de especificación (por ejemplo, relaciones entre casos de uso) de forma tal que se evite la redundancia y se promueva el reuso y abstracción de comportamiento. En la práctica, estos instrumentos no son utilizados tanto como deberían y es necesario que los analistas revisen los documentos periódicamente para preservar la calidad de los requerimientos. Desafortunadamente, inspeccionar los documentos manualmente es una tarea compleja y ardua. Por ello, en este artículo presentamos un enfoque semi-automático que permite encontrar defectos en las especificaciones de casos de uso y solucionarlos por medio de refactorizaciones. El enfoque implementa heurísticas avanzadas para localizar los defectos (por ej., comportamientos duplicados) y mecanismos que agilizan su resolución. El enfoque fue evaluado en sistemas reales, obteniendo resultados preliminares prometedores.Sociedad Argentina de Informática e Investigación Operativa (SADIO

Refactorización Orientada a Aspectos de Aplicaciones Empresariales

La importancia de las aplicaciones empresariales en las organizaciones de hoy en día, hace que sea necesario facilitar su mantenimiento y evolución a lo largo de su existencia. Este tipo de aplicaciones de gran complejidad cuentan con diversas funcionalidades y requerimientos que cortan transversalmente su estructura, para lo cual otros mecanismos de mo dularización más allá de la orientación a objetos resultarían convenientes. Dado que muchas de las aplicaciones empresariales se implementan utilizando el framework Spring puede utilizarse el módulo de AOP que este provee para obtener una mejor separación de los concerns. Con este objetivo, en este trabajo se presentan dos casos de estudios en los cuales se refactorizan los crosscutting concerns de dos aplicaciones empresariales con el prop ósito de encapsularlos en asp ectos. Con el fin de simplificar la tarea de refactorizacion un conjunto de refactorings, inicialmente presentados para AspectJ fueron adaptados para ser utilizados con Spring/AOP.Sociedad Argentina de Informática e Investigación Operativ

Un enfoque para automatizar la refactorización de casos de uso

Llevar a cabo las actividades de captura y modelamiento de requerimientos no es una tarea sencilla. Ésta requiere realizar un análisis profundo de las necesidades de los clientes y demanda cierto grado de experiencia de los analistas. Para comunicar satisfactoriamente los requerimientos, se deben aprovechar los instrumentos provistos por las técnicas de especificación (por ejemplo, relaciones entre casos de uso) de forma tal que se evite la redundancia y se promueva el reuso y abstracción de comportamiento. En la práctica, estos instrumentos no son utilizados tanto como deberían y es necesario que los analistas revisen los documentos periódicamente para preservar la calidad de los requerimientos. Desafortunadamente, inspeccionar los documentos manualmente es una tarea compleja y ardua. Por ello, en este artículo presentamos un enfoque semi-automático que permite encontrar defectos en las especificaciones de casos de uso y solucionarlos por medio de refactorizaciones. El enfoque implementa heurísticas avanzadas para localizar los defectos (por ej., comportamientos duplicados) y mecanismos que agilizan su resolución. El enfoque fue evaluado en sistemas reales, obteniendo resultados preliminares prometedores.Sociedad Argentina de Informática e Investigación Operativa (SADIO

Método para el aprendizaje de entornos y lenguajes de programación basado en prototipado ágil

Este artículo describe un método de enseñanza para el aprendizaje de un lenguaje de programación y entornos de desarrollo asociados. Este procedimiento de aprendizaje está basado en el desarrollo de un proyecto de cierta complejidad a partir de prototipos incrementales de baja complejidad. El método se inspira en principios del proceso de Desarrollo Rápido de Aplicaciones y de la metodología Desarrollo Ágil de Software. Para alcanzar un efectivo aprendizaje se emplean técnicas como programación en pareja, integración continua, refactorización, etc. Los alumnos, de tercer curso de ingeniería informática, cuentan con una base previa en metodología de la programación orientada a objetos y con un dominio medio de algún otro lenguaje de programación. Este método evita el estudio exhaustivo de los elementos y estructuras del lenguaje de programación, así como de su API. El aprendizaje se basa en el desarrollo guiado y supervisado de prototipos de complejidad incremental, quedando en manos de los grupos alumnos el perfeccionamiento de los prototipos y su integración en un proyecto único. En todo el proceso se introduce el uso de herramientas CASE para la definición y seguimiento de requisitos, el diseño rápido y su ágil desarrollo y prueba. La experiencia se ha desarrollado en la asignatura Herramientas y Entornos de programación durante 3 cursos en la Escuela Superior de Informática de Ciudad Real de las Universidad de Castilla-La Mancha.SUMMARY - This paper describes an educational method for programming languages and tools. The learning process is based on the development of a project integrating incremental simple prototypes. The method combines principles of rapid application development (RAD) and Agile Software Development methodology. Some learning techniques are used such as pair programming, continuous integration, and refactoring. The students of computer engineering (undergraduates in their third-year), had knowledge in object-oriented methodology and they mastered some other programming language. This method avoids the exhaustive study of the elements and structures of the programming language and its APIs. The learning process is based on the supervised development of prototypes with incremental complexity. Students have to improve these prototypes and integrate them into a whole project. Throughout the process we introduce the use of CASE tools for defining and monitoring requirements, the rapid design and agile development and testing. The experience has been developed in the course Programming Tools and Environments during three years at the School of Computer Science in Ciudad Real (University of Castilla-La Mancha, Spain)Peer Reviewe

BUENAS PRÁCTICAS, UNA SOLUCIÓN PARA UN MEJOR DESARROLLO DE SOFTWARE

Este articulo tiene como objetivo principal dar a conocer una serie de buenas prácticas planteadas para un mejor desarrollo de software, basadas en las metodologías agiles más representativas se han propuesto unos valores, unas características, unos roles, unas prácticas y un ciclo de vida para el desarrollo de un proyecto de software, con lo cual se busca abarcar todo el proceso desde que surge una necesidad por parte de un cliente, hasta el momento en se tiene la seguridad de que el cliente está totalmente satisfecho con el producto. Estas prácticas planteadas buscan comprometer al equipo de trabajo e integrarlo al proyecto de una manera beneficiosa para las personas participantes, ya que pueden estar desde el inicio hasta la fase final del proyecto cumpliendo un rol u otro específicamente, logrando con esto reducción de tiempo, costos y otros

Un enfoque para automatizar la refactorización de casos de uso

Llevar a cabo las actividades de captura y modelamiento de requerimientos no es una tarea sencilla. Ésta requiere realizar un análisis profundo de las necesidades de los clientes y demanda cierto grado de experiencia de los analistas. Para comunicar satisfactoriamente los requerimientos, se deben aprovechar los instrumentos provistos por las técnicas de especificación (por ejemplo, relaciones entre casos de uso) de forma tal que se evite la redundancia y se promueva el reuso y abstracción de comportamiento. En la práctica, estos instrumentos no son utilizados tanto como deberían y es necesario que los analistas revisen los documentos periódicamente para preservar la calidad de los requerimientos. Desafortunadamente, inspeccionar los documentos manualmente es una tarea compleja y ardua. Por ello, en este artículo presentamos un enfoque semi-automático que permite encontrar defectos en las especificaciones de casos de uso y solucionarlos por medio de refactorizaciones. El enfoque implementa heurísticas avanzadas para localizar los defectos (por ej., comportamientos duplicados) y mecanismos que agilizan su resolución. El enfoque fue evaluado en sistemas reales, obteniendo resultados preliminares prometedores.Sociedad Argentina de Informática e Investigación Operativa (SADIO

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í

Métodos ágiles para el desarrollo de software

Un método de desarrollo de software ágil es aquel capaz de adaptarse a los cambios, especialmente de los requisitos, según el feedback constante y temprano del cliente. El objetivo es minimizar el tiempo y el coste de realizar un proyecto de software, pero manteniendo la calidad. Todo esto se traduce en un ímpetu por las pruebas continuas, preferentemente automatizadas, y la integración continua para crear versiones de forma seguida para poderlas mostrar al cliente y recoger su opinión. Los métodos ágiles comparten un sustrato: el manifiesto ágil y los 12 principios ágiles, donde no se detallan trucos de programación sino recomendaciones para las personas dedicadas al proyecto. Se trata más de una manera de actuar, a alto nivel, que de prácticas específicas a bajo nivel, que se dejan a la elección de los propios programadores y su experiencia. En primer lugar, se dará una perspectiva concisa de los métodos predecesores. Seguidamente, se analizarán los 14 métodos ágiles más comunes, detallando el proceso con sus fases, las prácticas, papeles, workproducts o artefactos que se generan en cada fase, etc. También se mostrarán herramientas software que ayudan a adoptar prácticas ágiles o el método completo. Se verán las estadísticas sobre los puntos débiles de los métodos pesados y sus consecuencias, especialmente el Chaos Report (1994), y la mejora que ha supuesto la aplicación de prácticas o métodos ágiles desde entonces. Como conclusiones, se resumirán las muchas similitudes entre los diferentes métodos. También se discutirán ventajas e inconvenientes de las prácticas ágiles, muchas de ellas basadas en la experiencia y el sentido común, pero que pocas veces seaplican todas juntas para lograr una gestión rápida y adecuada

Desarrollo de un framework con una arquitectura basada en microservicios para el UP-Grade del Sistema de Planificación de Recursos Empresariales de la UCSM

La tecnología se encuentra en constante evolución, y constantemente podemos ver que surgen nuevas maneras de hacer software que buscan estar mejor preparadas para el entorno de alto crecimiento que estamos viviendo. Sin embargo, muchas organizaciones han decidido mantener sistemas con tecnologías antiguas y presentan una alta resistencia al cambio. Esto en consecuencia genera una mayor cantidad de riesgos, además de generar un mayor costo de mantenimiento. Es por estos motivos que en el presente trabajo se busca proponer un framework para realizar la refactorización y mejora del backend de un sistema, tomando como caso de estudio el ERP de la Universidad Católica de Santa María