Faltas en el aprendizaje del modelado de clases y casos de uso: una revisión sistemática

Introducción

De acuerdo con Aguilar et al. (2017), se entiende por diseño al proceso de definición de arquitectura, componentes, interfaces y otras características del sistema de software, así como del producto de dicho proceso.

En el contexto del paradigma orientado a objetos surgido en la década de 1980, se desarrollaron métodos, modelos y técnicas que permiten generar representaciones relacionadas con la estructura y el comportamiento del software a construir. Años más tarde, el esfuerzo por la unificación de dichos métodos y modelos dio origen a un estándar de diseño en la ingeniería de software que hoy se conoce como lenguaje modelado unificado (UML por su sigla en inglés) (Rumbaugh, Jacobson y Booch, 2000).

Como parte del proceso de verificación, es necesario realizar una serie de revisiones al diseño, y de acuerdo con Brunet, Guerrero y Figueiredo (2009), este proceso consiste en un mecanismo para encontrar faltas en el diseño y su representación. En este sentido, proponer una técnica para encontrar faltas, específicamente en el modelado del diseño de software, resulta un área de investigación que puede aportar elementos innovadores en la ingeniería de software.

Para efecto de distinguir entre cuatro conceptos muy relacionados que suelen ser utilizados de manera indistinta, en el estudio se consideró la propuesta de Juristo, Moreno y Vegas (2006), la cual considera:

• Error: acción humana que produce una falta.

• Falta: algo que está mal en un producto (modelo, código, documento, etc.).

• Fallo: manifestación de una falta.

• Defecto: error, falta o fallo.

Esta investigación es el inicio de un proyecto relacionado con la detección de faltas en los diagramas UML, en este artículo se presenta específicamente una revisión de los estudios primarios publicados para la identificación de faltas durante el aprendizaje de los diagramas de casos de uso y diagramas de clase en los últimos 10 años.

El presente artículo se encuentra organizado de la siguiente manera: la segunda sección presenta conceptos básicos sobre el diseño de software y el lenguaje de modelado unificado; en la tercera sección se presentan los trabajos relacionados; la cuarta sección describe la metodología de investigación utilizada para la revisión sistemática de la literatura (RSL); la quinta sección describe la planificación del estudio basada en la metodología de la sección anterior; en la sexta sección está la ejecución de dicho estudio; y la séptima sección muestra los resultados obtenidos de la RSL. Finalmente, la octava sección refiere las conclusiones y los trabajos futuros.

Modelado del software

Una de las fases del desarrollo de un producto de software es el diseño, este permite modelar el sistema o software a construir; esta fase comienza una vez que se han analizado y especificado los requisitos, y se realiza antes de la fase de codificación (Figura 1).

Figura 1: Dualidad Proceso-Producto en la Ingeniería de Software.

Fuente: Aguilar, Oktaba y Juárez (2019)

Los modelos derivados del diseño pueden analizarse desde dos dimensiones distintas: dimensión del proceso y dimensión de la abstracción (Figura 2). La dimensión del proceso indica la evolución del modelo del diseño conforme se ejecutan las tareas de este como parte del proceso del software; por su parte, la dimensión de la abstracción representa el nivel de detalle a medida que cada elemento del modelo de análisis se transforma en un equivalente de diseño y luego se mejora en forma iterativa. La Figura 2 permite observar una línea discontinua que representa la frontera entre los elementos del modelo de análisis y del modelo de diseño. Así mismo, los elementos del modelo de diseño usan muchos de los diagramas UML que se utilizaron en el modelo del análisis (Pressman y Maxim, 2021).

Figura 2: Dimensiones del modelo de diseño.

Fuente: Pressman y Maxim (2021)

En los últimos años el lenguaje de modelado unificado se ha consolidado como una de las mejores herramientas de modelado con el que se han establecido los procesos del diseño del software. El UML nos permite presentar los aspectos muy variados de un sistema de software, por ejemplo: requisitos, estructuras de datos, flujos de datos y flujos de información, lo anterior utilizando conceptos orientados a objetos (Seidl, 2015).

Cabe destacar que el UML permite modelar la gran mayoría de los diagramas encontrados tanto de la dimensión del proceso como en la dimensión de abstracción. En la Tabla 1 se presentan los diagramas de este lenguaje de modelado agrupado por áreas y vistas, así como los conceptos principales de cada uno de los diagramas.

Tabla 1: Vistas y diagramas UML.

Metodología

En el contexto de los estudios secundarios, una revisión sistemática de la literatura (RSL) permite identificar, evaluar e interpretar la investigación disponible en la literatura, que resulta relevante para una pregunta de investigación, un área temática o un fenómeno de interés (Genero, Cruz-Lemus y Piattini, 2014).

En el caso del presente estudio, los autores utilizaron la guía propuesta por Kitchenham y Charters (2007), cuyo desarrollo consiste en tres etapas:

1. Planificación: las principales tareas de esta primera etapa consisten en: identificar la necesidad de la revisión, formular las preguntas de investigación, definir el protocolo de la revisión, y validar el protocolo de la revisión.

2. Ejecución: la segunda etapa tiene como principales tareas: identificar la investigación relevante, seleccionar los estudios primarios relevantes para el estudio, evaluar la calidad de los estudios primarios seleccionados, extraer la información vinculada con las preguntas de investigación y sintetizar la información extraída.

3. Difusión: una vez realizada la RSL, las tareas que integran la tercera etapa consisten: redactar el informe de la revisión, validar el informe y, a juicio de los autores, se debería incluir la difusión de los hallazgos.

Ejecución del estudio

En esta fase de estudio la actividad principal consistió en realizar el proceso de indagación de acuerdo con la cadena de búsqueda en las fuentes descritas en la sección anterior y como resultado se obtuvo un conjunto de estudios primarios para la investigación. En la Tabla 2 se puede observar la cadena utilizada en cada BD.

Tabla 2: Cadenas configuradas por cada base de datos.

Los documentos encontrados se muestran en la Tabla 3. Primero se buscaron en las tres bases de datos previamente seleccionadas. Se obtuvieron 1.884 artículos, y 1.856 artículos fueron descartados después de aplicar un primer filtrado con los criterios de inclusión y otros ocho en un segundo filtrado con los criterios de exclusión. Con el segundo filtrado, tres documentos de la IEEE y dos de Springer no se obtuvieron completos; también se encontraron tres documentos duplicados en ACM. Luego de ese proceso, quedaron 20 documentos distribuidos de la siguiente manera: IEEE (8 documentos, 40 %), ACM (7 documentos, 35 %) y Springer (5 documentos, 25 %).

Tabla 3: Resultados de la búsqueda.

Como se puede observar en la Figura 3, durante los últimos 10 años no ha existido una tendencia de publicación en ningún sentido, ciertamente se observan picos que fluctúan a lo largo de la década; se puede decir que el número de publicaciones por año es de dos en promedio.

Figura 3: Número de EPS por año.

En la Tabla 4 se presenta el conjunto de artículos seleccionados por base de datos, así como el tipo de publicación; se puede observar que en un 70 % las publicaciones se han presentado en memorias de congresos.

Tabla 4: Estudios Primarios seleccionados por BD y Tipo de Publicación.

Como mecanismo para la evaluación de la calidad de los estudios primarios seleccionados, se consideró como criterio la completitud que puede tener cada estudio seleccionado para dar respuesta a las preguntas de investigación; así, un estudio podrá tener una valoración entre 0 y 1, según dé respuesta a las preguntas de investigación; por ejemplo, el Art_02 al dar respuestas a las preguntas 2 y 4 tuvo una valoración de 0,50 (Tabla 5).

Tabla 5: Evaluación de la calidad de los estudios primarios seleccionados.

De acuerdo con la Tabla 5 se puede observar que el conjunto de artículos seleccionados resultó tener una calidad apropiada para el estudio, ya que cada uno dio respuesta a al menos a una pregunta de investigación e incluso en el 33 % de los casos dio respuesta a dos.

Resultados

En esta sección se presentan los resultados obtenidos del estudio, los cuales permiten conocer propuestas para faltas en el lenguaje de modelado unificado, específicamente en los diagramas de casos de uso y en los diagramas de clases, lo anterior tanto en el ámbito educativo como en la práctica profesional. A continuación, se presentan las respuestas a las preguntas de investigación que fueron planteadas en la presente revisión sistemática de la literatura.

A. PI1. ¿Cuáles son las características de las tipologías propuestas para faltas comunes en los diagramas de casos de uso?

De los estudios primarios elegidos, en Hakim, Sellami y Ben-Abdallah (2017) se identificó que los autores proponen una aproximación para detectar y localizar errores de inter-consistencia en los diagramas de casos de uso; dicha aproximación está basada en dos fases: fase de medición y fase de control.

• La fase de medición consiste en medir el tamaño funcional y el tamaño estructural del diagrama de caso de uso, para esto los autores usan un mapeo de los elementos del diagrama de casos de uso.

• La fase de control consiste en aplicar una serie de reglas para identificar y localizar los errores de inter-consistencia; es decir, proponen reglas de consistencia que se relacionan con la consistencia vertical entre la especificación y los modelos de diseño.

Similarmente, Shuang et al. (2014) proponen la detección automática de defectos en los documentos de casos de uso aprovechando técnicas avanzadas de análisis (parsing). La propuesta también consiste en dos fases. En la primera fase, a partir de los documentos de caso de uso, se examina cada sentencia dentro un análisis de árbol (dependencia y estructura), posteriormente, en la segunda fase, a partir del análisis de árbol, se genera un diagrama de actividades para cada caso de uso, como salida además del diagrama de actividades se obtiene el reporte de defectos.

Tianual y Pohthong (2019) proponen una técnica para la detección de defectos en las vistas de casos de uso durante la fase de análisis o ingeniería de requisitos; dicha propuesta usa los requisitos de los usuarios escritos en una especificación basada en un formulario para comparar. En este caso los defectos en los casos de uso los categorizan en el flujo incorrecto entre los casos de uso y la meta no alcanzada.

Por otra parte, Chourio et al. (2019) confeccionaron una metodología obteniendo como resultado una propuesta de los errores más comunes al usar UML. La metodología consta de cuatro etapas: levantamiento teórico de errores, seguimiento de las actividades del curso, análisis de los registros de etapa anterior y elaboración del catálogo de errores. En la primera etapa realizan una revisión de la literatura para encontrar los errores comunes en el modelado; en la segunda etapa verifican si los errores descritos en la literatura suceden en la práctica; en la tercera etapa realizan un análisis de la etapa anterior y en la última etapa proponen un catálogo de errores; para efectos del estudio, se adoptara el concepto de faltas para la tipología de errores propuesta. En la Tabla 6 se presentan las faltas identificadas en los diagramas de casos de uso.

Tabla 6: Faltas comunes en los diagramas de casos de uso.

En los estudios se encontró que otra forma de detectar faltas en los casos de uso es implementando verificación formal; por ejemplo, Claret y Régis-Gianas (2015) proponen una técnica para representar programas interactivos y casos de uso formalmente verificados; sin embargo, los autores no mencionan las faltas a detectar en los casos de uso. Algo similar ocurre en Parachuri et al. (2014) y Simko et al. (2012), es decir, proponen la verificación formal para la revisión de los casos de uso; no obstante, el estudio es en los documentos no en los diagramas casos de uso.

Finalmente, Chaudron et al. (2014) presentan una selección de evidencia empírica relacionada con la efectividad del UML; para esto analizan el costo y el beneficio del modelado expresando que un parámetro que explica el costo del modelado es el tamaño del modelo, pero también la falta de soporte de herramientas es importante. En este mismo estudio, interesados por la falta de preocupación de los grados de incompletitud e inconsistencias en los modelos UML, para ello mencionan que también realizaron un experimento donde utilizaron modelos UML, con y sin defectos a sujetos que consistían en estudiantes y profesionales; sin embargo, no describen ni mencionan cuáles son esos defectos.

B. PI2. ¿Cuáles son las características de las tipologías propuestas para faltas comunes en los diagramas de clases?

Continuando con los estudios primarios elegidos, tal como se comentó en la respuesta de la pregunta de investigación anterior, Chourio et al. (2019) confeccionaron una metodología y obtuvieron como resultado una propuesta de los errores más comunes al usar UML; en la Tabla 7 se presentan los errores comunes propuestos en su estudio para los diagramas de clases.

Tabla 7: Faltas comunes en los diagramas de clases.

Fuente: Chourio et al. (2019)

Kayama et al. (2014) presentan los resultados de un análisis de errores en los diagramas de clase; estos resultados se obtienen de un estudio donde los autores exploran métodos educativos para el modelado conceptual de alumnos principiantes o novatos. Cabe mencionar que previo al estudio que presentan, los autores recolectaron y analizaron de 2010 a 2013 los errores en todos los diagramas finales de los estudiantes novicios, y a partir de eso proponen cuatro categorías de errores: sintácticos, relacionados con los atributos, relacionados con la asociación y relacionados con la clase. Estas categorías son las que organizaron para explorar sus métodos educativos; el resultado de los errores encontrados en los diagramas de clase en los métodos de enseñanza se presenta en la Tabla 8.

Tabla 8: Faltas a considerar en los métodos de enseñanza.

Fuente: Kayama et al. (2014).

Por otro lado, Halim (2013) propone un modelo para medir la complejidad del software orientado a objetos en la fase de diseño para predecir las clases propensas a fallas. Así mimo, el autor menciona que el modelo de predicción se construye utilizando dos algoritmos de clasificación: Naive Bayesian y k-vecinos más cercanos.

Para el experimento presentado en este estudio utiliza ingeniería inversa, es decir a partir del código fuente genera las clases y sus relaciones; sin embargo, en ninguna sección del estudio comenta sobre las faltas que detectan en los diagramas de clases.

De manera similar a los diagramas de casos de uso, se encontró que otra forma de detectar fallas en los diagramas de clase es implementado verificación formal; por ejemplo, en Shaik y Wiil (2018), la propuesta consiste en transformar los diagramas de clases UML en código junto con sus restricciones del lenguaje de especificación de objetos (OCL, por su sigla en inglés), para esto, los autores con el objetivo de obtener una verificación eficiente, proponen el uso de verificación formal con técnicas de corte y retroalimentación. Antes de la transformación, proponen encontrar defectos en el modelo, para esto se verifica que las clases tengan su estructura típica junto con sus asociaciones correspondientes, estas de listan en la Tabla 9.

Tabla 9: Estructura y relaciones de clases

También Clarisó et al. (2019) proponen verificación formal, pero a diferencia de Shaik y Wiil (2018), ellos presentan técnicas de verificación limitada, por ejemplo, solucionadores de programación de especificación (CP).

Chebanyuk y Markov (2016) proponen una verificación en los diagramas de clases utilizando principios de diseño SOLID, donde SOLID representa cinco principios básicos de la programación orientada a objetos y a diseño, estos son: principio de responsabilidad única, principio de abierto cerrado, principio de sustitución de Liskov, principio de segregación de la interfaz y principio de inversión de la dependencia.

Parachuri et al. (2014), Motta (2012), Baresi et al. (2012), Shaikh y Wiil (2012), Wu (2022) y Sadowska y Huzar (2017) también plantean verificación formal en la revisión de los diagramas de clase, por ejemplo, Motta (2012), Baresi et al. (2012) y Sadowska y Huzar (2017) proponen una semántica formal; sin embargo, en los documentos no mencionan los errores buscados.

C. PI3. ¿Cuáles son las características de las herramientas para verificación de diagramas de casos de uso con base en las taxonomías propuestas?

De los estudios primarios elegidos y relacionados con esta pregunta de investigación, en Shuang et al. (2014) se encontró que los autores proponen algoritmos para verificar automáticamente defectos relacionados con la coherencia y la integridad en los casos de uso, pero esta verificación está en los documentos de caos de uso no en los diagramas de casos uso.

Por otro lado, Agner et al. (2019) presentan una revisión de la literatura relacionada con las herramientas UML más importante que permita al estudiante determinar sus fortalezas y debilidades en el modelado; lo interesante de este estudio es la presentación de las herramientas UML que se pueden utilizar en el diseño de software, pero no se hace mención en el estudio de alguna herramienta que detecte fallas en los diagramas de casos de casos de uso.

Shaikh y Wiil (2018), para la verificación formal de los diagramas de clases, utilizan una herramienta llamada UMLtoCSP. La herramienta recibe como entrada un diagrama de clases con restricciones OCL y verifica automáticamente la precisión de las propiedades.

En general, dentro de los resultados de los estudios primarios elegidos se observó que no hay una herramienta en específico para detectar faltas en los diagramas de casos de uso, en la mayoría de los estudios revisados se realiza manualmente.

D. PI4. ¿Cuáles son las características de las herramientas para verificación de diagramas de clases con base en las taxonomías propuestas?

En cuanto a las herramientas para la detección de faltas en los diagramas de clases, Halim (2013) comenta que para la recopilación de datos utilizó cuatro versiones de JEdit, esta herramienta es un proyecto de código abierto basado en JAVA; sin embargo, tal como se comentó en la respuesta a la pregunta de investigación anterior, no se mencionan las faltas que se detectan en los diagramas de clases.

Vanwormhoudt et al. (2017) presentan el uso plantillas aspectuales, el cual requiere que los parámetros formen un modelo de sistemas que inyecten nuevas funcionalidades. En el UML estándar, una plantilla es un modelo que expone algunos de sus elementos como parámetros; por ejemplo, las clases o los paquetes son denominados plantillas de clase o plantillas de paquete, respectivamente. Lo interesante de este estudio es la presentación de una herramienta para asistir en la construcción de sistemas UML con plantillas aspectuales; por ejemplo, plugins para eclipse, pero no se menciona en el estudio de alguna herramienta que detecte fallas en los diagramas de clases.

Finalmente, como se comentó en la respuesta a la pregunta de investigación PI2, algunos autores proponen verificación formal para el estudio de los diagramas de clases (Motta, 2012; Shaikh y Wiil, 2018; Wu, 2022), así como también proponen una herramienta de desarrollo propio.

Conclusiones

En este estudio se presentó una revisión sistemática de la literatura relacionada con la detección de faltas comunes durante el aprendizaje del modelado con diagramas de UML, específicamente en los diagramas de casos de uso y diagramas de clase. La investigación se basó en los estudios de los últimos 10 años publicados en las bases de datos IEEE, ACM y Springer.

Siguiendo el protocolo de investigación planteado se seleccionaron y analizaron 20 estudios primarios reportados; con lo anterior, se observa en primera instancia que el número de estudios recuperados fue escaso y, por otro lado, el tipo de publicaciones en su gran mayoría (70 %) proviene de memorias de congresos, por tal motivo se puede concluir que la investigación en torno a las tipologías de faltas en los diagramas UML es incipiente, en particular, diagramas de casos de uso y diagramas de clases.

En relación con el uso de alguna herramienta de software, se encontró que se utilizó alguna herramienta de desarrollo propio; sin embargo, para los diagramas de casos de uso se enfocaron más en los documentos de casos de uso que en los diagramas UML. Algo similar ocurre con los diagramas de clases, en estos estudios utilizan métodos formales para la verificación de los diagramas; sin embargo, no presentan cuáles son las faltas comunes que verifican.

Como trabajos futuros se considera repetir la revisión sistemática en otras bases de datos para los dos diagramas presentados en este artículo; hacer la revisión sistemática considerando los otros tipos de diagramas UML; así como proponer una taxonomía de faltas y realizar un estudio primario para su validación.