Abstract:

Los sistemas de software modernos se caracterizan principalmente por su creciente complejidad y tamaño. Por esta razón, el diseño arquitectónico de software se ha convertido en un aspecto esencial en el éxito de la mayoría de los proyectos. Una de las transiciones más complejas del proceso de desarrollo de software es la que ocurre entre la especificación de los requerimientos y su diseño arquitectónico. En este sentido, se cuenta con pocos métodos disponibles para asistir o guiar a los arquitectos de software en esa tarea, quienes deben seguir su intuición y experiencia para concebir la arquitectura del sistema. Este trabajo final propone un enfoque para ayudar a reducir la brecha entre las especificaciones de requerimientos y el diseño arquitectónico, a través de la generación asistida de Use Case Maps. En primer lugar se realizará la clasificación de los requerimientos del sistema para poder discriminar entre funcionales y no funcionales. Para realizar la clasificación de los mismos, se exploraron técnicas de clasificación como KNN y Naive-Bayes usando un conjunto de requerimientos previamente clasificados de forma manual para el entrenamiento de los clasificadores. Entre estos algoritmos, los resultados obtenidos indicaron que KNN es mejor para realizar la clasificación, obteniendo un accuracy superior al 98% y un recall superior al 82% para la identificación de requerimientos funcionales. Una vez clasificados, se analizarán los requerimientos funcionales con el objetivo de obtener un conjunto de responsabilidades que deberá cumplir el sistema para contemplar todas las funcionalidades del mismo. Para ello se utilizaron técnicas propias del procesamiento del lenguaje natural como Part of Speech Tagging para identificar las responsabilidades. Usando 5 proyectos de ejemplo, los resultados indicaron un accuracy entre 71% para el peor caso y un 100% para el mejor caso. Entre estos proyectos, el recall obtenido fue de 63% para el peor caso y 100% para el mejor caso. Finalmente, en base a estas responsabilidades se generarán Use Case Maps que ayudarán al arquitecto durante las etapas iniciales del diseño del sistema. Para ello se usarán técnicas del procesamiento del lenguaje natural, analizando los tiempos verbales, las preposiciones y las frases condicionales contenidas en los requerimientos para encontrar relaciones entre las responsabilidades identificadas. A la hora de buscar las menciones de responsabilidades en las diferentes oraciones de los requerimientos, se propusieron 2 estrategias. La primera consistió en usar “string matching” para buscar menciones de los verbos o sustantivos de las responsabilidades en las oraciones. La segunda fue la de incluir el uso de ontologías para la detección de las menciones de dichas responsabilidades en las oraciones. Es importante aclarar que en ambas estrategias, se acude al usuario para validar las relaciones detectadas. Al analizar ambas estrategias, usando 3 proyectos de estudio, la segunda estrategia que hace uso de ontologías obtuvo valores más altos de recall para los 3 proyectos, dando un promedio de 92% contra 68 %. En cuanto al accuracy obtenido, el uso de ontologías demostró comportarse mejor para 2 de los 3 proyectos, dando un promedio de 81% para la estrategia con ontologías contra 73% para la estrategia sin uso de ontologías. Sin embargo en el caso del proyecto en donde dio un accuracy inferior a la primera estrategia, la diferencia fue de tan solo del 5% para dicho proyecto. Adicionalmente, en ésta etapa se intentarán identificar los componentes del sistema y las responsabilidades de cada uno de ellos. En esta tarea se propuso 2 estrategias: la primera consiste en usar el algoritmo de clústering KMeans para agrupar las distintas responsabilidades en componentes conceptuales, en donde se obtuvo entropías superiores al 64 %; la segunda consiste en hacer uso de ontologías para determinar relaciones entre las responsabilidades y diferentes componentes definidos en la ontología, en donde la entropía obtenida fue de 0% para todos los casos. Sin embargo, luego de la evaluación de las 2 estrategias, se decidió excluir el uso de KMeans para la identificación de los componentes. Esto se decidió no solo por los resultados de entropía obtenidos, sino por que conceptualmente los componentes identificados no se corresponderían con los componentes arquitectónicos del sistema. El simple hecho de que el agrupamiento tome como entrada únicamente las responsabilidades(las cuales fueron obtenidas a partir de los requerimientos funcionales) indica que no se tuvieron en cuenta los requerimientos no-funcionales. Esto generaría que los componentes identificados no se correlacionen con los atributos de calidad requeridos por el sistema. Luego de evaluar cada uno de los procesos de dicha estrategia, se concluyó que la misma resultó muy flexible en cuanto al formato de entrada de los requerimientos. También resultó muy buena en cuanto a la posibilidad de incluir información del contexto del proyecto gracias al uso de las ontologías. Sin embargo, la herramienta resultó ser muy sensible a los errores ortográficos, tanto léxicos como sintácticos. También es importante aclarar que la misma se encuentra limitada al idioma inglés.

Author affiliation: Lomagno, Cristian. Universidad Nacional del Centro de la Provincia de Buenos Aires. Facultad de Ciencias Exactas; Argentina

Author affiliation: Soria, Álvaro. Universidad Nacional del Centro de la Provincia de Buenos Aires. Facultad de Ciencias Exactas; Argentina

Author affiliation: Rodriguez, Guillermo. Universidad Nacional del Centro de la Provincia de Buenos Aires. Facultad de Ciencias Exactas; Argentina