· 2014-04-02 · Transformación de diagramas de actividad a código fuente en Java.....- 37 -...

i

Contenido Contenido ......................................................................................................................................... i Índice de Figuras ............................................................................................................................. v Índice de Tablas............................................................................................................................ viii Índice de Tablas............................................................................................................................ viii Glosario de términos....................................................................................................................... ix Glosario de términos....................................................................................................................... ix Resumen .......................................................................................................................................... x Abstract........................................................................................................................................... xi Capítulo 1. Introducción y antecedentes de la investigación.......................................................- 2 -

1.1. Introducción......................................................................................................................- 2 - 1.2. Antecedentes.....................................................................................................................- 3 - 1.3. Trabajos relacionados .......................................................................................................- 6 - 1.4. Descripción del problema...............................................................................................- 10 - 1.5. Objetivo ..........................................................................................................................- 10 - 1.6. Justificación....................................................................................................................- 10 - 1.7. Beneficios .......................................................................................................................- 11 - 1.8. Pregunta de investigación...............................................................................................- 11 - 1.9. Alcances y limitaciones ..................................................................................................- 12 -

1.9.1. Alcances ..................................................................................................................- 12 - 1.9.2. Limitaciones ............................................................................................................- 12 -

Capítulo 2. Marco conceptual....................................................................................................- 14 -

2.1. Introducción....................................................................................................................- 14 - 2.2. Modelado........................................................................................................................- 14 -

2.2.1. Diseño y la técnica de modelado .............................................................................- 15 - 2.2.2. Relaciones entre modelos ........................................................................................- 15 -

2.3. Lenguaje de modelado unificado UML..........................................................................- 15 - 2.3.1. Modelado estático...................................................................................................- 16 - 2.3.2. Modelado dinámico .................................................................................................- 16 -

2.4. Descripción de los diagramas de actividad.....................................................................- 17 - 2.5. Elementos contenidos en los diagramas de actividad.....................................................- 17 - 2.6. Lenguajes visuales..........................................................................................................- 19 -

2.6.1. Clasificación de las gramáticas visuales..................................................................- 19 - 2.6.2. Gramática visual relacional .....................................................................................- 19 -

2.7. Generación de código a partir de diagramas de actividad..............................................- 20 - 2.8. Métricas de los diagramas UML ....................................................................................- 20 -

2.8.1. Métricas de Chidamber y Kemere ...........................................................................- 21 - 2.8.1.1. Estructura del flujo de control ..........................................................................- 22 - 2.8.1.2. Grafo de flujo de control ..................................................................................- 22 -

2.8.2. Métricas de estructuras de control ...........................................................................- 23 -

ii

2.8.2.1. Prueba de la ruta base. ......................................................................................- 23 - 2.8.2.2. Notación de gráficos de flujo............................................................................- 23 - 2.8.2.3. Ruta independiente de programa ......................................................................- 24 -

2.8.3. Medida de complejidad ciclomática de Mc Cabe....................................................- 25 - 2.8.4. Cuenta de decisión (DE)..........................................................................................- 26 - 2.8.5. Métricas compuestas................................................................................................- 27 - 2.8.6. Métrica propuesta ....................................................................................................- 27 - 2.8.7. Ejemplo de la métrica propuesta .............................................................................- 29 -

2.9 Conclusiones del capitulo................................................................................................- 31 - Capítulo 3. Metodología de solución.........................................................................................- 34 -

3.1. Introducción....................................................................................................................- 34 - 3.2. Procedimiento de transformación de diagramas de actividad a código..........................- 35 - 3.3. Análisis de los diagramas de actividad y la codificación ...............................................- 38 -

3.3.1. Estructuras de selección...........................................................................................- 38 - 3.3.1.1. Características de la región de expansión condicional .....................................- 40 -

3.3.2. Estructuras de repetición .........................................................................................- 42 - 3.3.3. Estructuras de ejecución concurrente ......................................................................- 43 - 3.3.4. Restricciones de las regiones de expansión.............................................................- 44 -

3.4. Reglas generadas ............................................................................................................- 49 - 3.4.1. Reglas que pertenecen al símbolo inicio .................................................................- 49 -

3.4.1.1. Símbolo inicio y símbolo fin ............................................................................- 49 - 3.4.1.2. Símbolo inicio y símbolo actividad..................................................................- 49 - 3.4.1.3. Símbolo inicio y símbolo condición.................................................................- 49 - 3.4.1.4. Símbolo inicio y símbolo merge.......................................................................- 50 - 3.4.1.5. Símbolo inicio y símbolo concurrencia inicio..................................................- 50 - 3.4.1.6. Símbolo inicio y concurrencia fin ....................................................................- 50 -

3.4.2. Reglas que pertenecen al símbolo final. ..................................................................- 51 - 3.4.2.1. Inconsistencias con el símbolo fin....................................................................- 51 -

3.4.3. Reglas que pertenecen al símbolo actividad............................................................- 51 - 3.5. Gramática visual relacional ............................................................................................- 53 -

3.5.1. Gramática visual relacional de los diagramas de actividad.....................................- 53 - 3.5.1.1. Atributos (Attr) .................................................................................................- 53 -

3.5.2. Reglas de producción ..............................................................................................- 54 - 3.5.2.1. Desde el estado inicial ......................................................................................- 54 - 3.5.2.2. Desde el estado final.........................................................................................- 54 - 3.5.2.3. Desde el estado Actividades .............................................................................- 54 - 3.5.2.4. ActividadesConFin ...........................................................................................- 54 - 3.5.2.5. Desde el estado ActividadesConcurrentes........................................................- 54 - 3.5.2.6. Desde el estado Estructuras ..............................................................................- 55 - 3.5.2.7. Desde el estado Secuencial...............................................................................- 55 - 3.5.2.8. Desde el estado Concurrencia...........................................................................- 55 - 3.5.2.9. Desde el estado Ciclo .......................................................................................- 55 - 3.5.2.10. Desde el ciclo While.......................................................................................- 56 - 3.5.2.11. Desde el ciclo DoWhile..................................................................................- 56 - 3.5.2.12. Desde el ciclo For ...........................................................................................- 56 -

iii

3.5.2.13. Desde el estado Condicional ..........................................................................- 56 - 3.5.2.14. Desde el estado IfElse ....................................................................................- 57 - 3.5.2.15. Desde el estado If ...........................................................................................- 57 -

3.6. Conclusiones del capítulo...............................................................................................- 57 - Capítulo 4. Validación del procedimiento de transformación...................................................- 60 -

4.1. Introducción....................................................................................................................- 60 - 4.2. Escenarios para los casos de uso de ADCODE..............................................................- 63 -

4.2.1. Escenario para el CU1_Diagramar ..........................................................................- 63 - 4.2.2. Escenario para el CU2_GenerarCódigo ..................................................................- 64 -

4.3. Diagramas de Secuencias ...............................................................................................- 65 - 4.3.1. Diagrama de secuencias de generar código.............................................................- 65 - 4.3.2. Diagrama de secuencias para diagramar .................................................................- 66 -

4.4. Diagramas de clases .......................................................................................................- 66 - 4.5. Utilización de la herramienta..........................................................................................- 71 -

4.5.1. Diagramador ............................................................................................................- 71 - 4.5.2. Generación de código ..............................................................................................- 74 - 4.5.3. Herramientas............................................................................................................- 75 -

4.6. Conclusiones del capítulo...............................................................................................- 76 - Capítulo 5. Pruebas de la herramienta que valida el procedimiento de transformación ...........- 78 -

5.1. Introducción...................................................................................................................- 78 - 5.2. Plan de pruebas...............................................................................................................- 78 -

5.2.2. Convención de nombres ..........................................................................................- 78 - 5.2.3. Elementos de prueba................................................................................................- 78 - 5.2.4. Características que serán probadas ..........................................................................- 79 - 5.2.5. Características que no se probarán ..........................................................................- 79 - 5.2.6. Enfoque....................................................................................................................- 79 - 5.2.7. Criterios de éxito o fracaso.....................................................................................- 79 -

5.2.7.1. Los criterios de éxito ........................................................................................- 79 - 5.2.7.2. Los criterios de fracaso.....................................................................................- 80 -

5.2.8. Criterios de la suspensión y requisitos para la reanudación ....................................- 80 - 5.2.9. Entregables de pruebas ...........................................................................................- 80 - 5.2.10. Tareas de pruebas ..................................................................................................- 80 - 5.2.11. Necesidades del entorno ........................................................................................- 80 - 5.2.12. Riesgos y contingencias ........................................................................................- 81 - 5.2.13. Aprobaciones.........................................................................................................- 81 -

5.3. Especificaciones de casos de prueba (CP)......................................................................- 81 - 5.4. Especificación de procedimientos de prueba (EP) .........................................................- 84 -

5.4.1. EP01. Clase Card: Métodos Card( ) y getNumber( )..............................................- 85 - 5.4.2. EP02. Clase Status: Método toString( )...................................................................- 88 - 5.4.3. EP03. Clase LOG: Métodos Log ( ), LogSend ( ) y LogResponse ( ).....................- 91 - 5.4.4. EP04. Clase CustomerConsole: Métodos readPin ( ), readMenuChoice ( ) y readAmount ( ) ..................................................................................................................- 94 - 5.4.5. EP05. Clase ReceiptPrinter: Métodos PrintReceipt ( )..........................................- 102 -

iv

5.5. Reporte de incidentes de prueba (RI) ...........................................................................- 105 - 5.6. Reportes de resumen de prueba (RR) ...........................................................................- 106 - 5.7 Conclusiones del capítulo..............................................................................................- 107 -

Capítulo 6. Resultados.............................................................................................................- 110 -

6.1. Introducción..................................................................................................................- 110 - 6.2 Conclusiones..................................................................................................................- 110 -

6.2.1. Beneficios Obtenidos.............................................................................................- 111 - 6.2.2. Limitaciones ..........................................................................................................- 111 -

6.3. Trabajos Futuros ...........................................................................................................- 112 - Anexo A. Reporte de diseño de ADCODE. ............................................................................- 114 -

A.1. Diagramas de Caso de Uso..........................................................................................- 114 - A.2. Diagrama de paquetes..................................................................................................- 115 - A.3. Diagrama de clases ......................................................................................................- 116 - A.4. Diagramas de estados ..................................................................................................- 118 -

A.4.1. Diagrama de estados de Elemento gráfico del diagrama......................................- 118 - A.5. Diagramas de actividad ...............................................................................................- 118 -

A.5.1. Diagrama de actividad de elemento gráfico .........................................................- 118 - A.5.2. Diagrama de actividad para generar código .........................................................- 119 -

Anexo B. Utilización de ADCODE.........................................................................................- 122 - B.1. Creación de diagrama de actividad ..............................................................................- 122 - B.2. Eliminación de elementos gráficos del diagrama de actividad....................................- 124 - B.3. Generación de código. .................................................................................................- 124 -

Referencias bibliográficas .......................................................................................................- 127 -

v

Índice de Figuras Figura 1.1. Arquitectura de Mango [ALF06]. .............................................................................- 5 - Figura 1.2. Evolución de Mango [ALF06]. .................................................................................- 5 - Figura 1.3. Porcentaje de defectos removidos por etapa. ..........................................................- 11 - Figura 2.1. Relación de los conceptos del marco conceptual....................................................- 14 - Figura 2.2. Representación de una actividad.............................................................................- 17 - Figura 2.3. Representación de una transición............................................................................- 18 - Figura 2.4. Representación de los símbolos de inicio y fin de una transición...........................- 18 - Figura 2.5. Representación de la bifurcación mediante un símbolo con forma de rombo. .......- 18 - Figura 2.6. Ejemplo de división y unión. ..................................................................................- 18 - Figura 2.7. Transformación de diagramas de actividad a código..............................................- 20 - Figura 2.8. Notación de gráfico de flujo [PRE05].....................................................................- 23 - Figura 2.9. Representación de un diagrama de flujo en un gráfico de flujo [PRE05]...............- 24 - Figura 2.10. Gráfico de flujo de una sentencia con condición compuesta [PRE05] .................- 24 - Figura 2.11. Números ciclomáticos de dos diagramas de flujo.................................................- 26 - Figura 2.12. Procedimiento para obtener la complejidad ciclomática [PRE05] .......................- 29 - Figura 2.13. Diagrama de actividad del programa de la figura anterior....................................- 30 - Figura 3.1. Representación de las regiones de expansión condicionales en diagramas de actividad y su representación en código fuente.........................................................................................- 34 - Figura 3.2. Diagrama de actividad del procedimiento de transformación.................................- 35 - Figura 3.3. Texto en diagramas de actividad.............................................................................- 36 - Figura 3.4. Transformación de diagramas de actividad a código fuente en Java ......................- 37 - Figura 3.5. Sintaxis sugerida por [STO04c] para los nodos condicionales...............................- 39 - Figura 3.6. Representación del modelado de las estructuras de selección para diagramas de actividad. ...................................................................................................................................- 39 - Figura 3.7. Región de expansión condicional con flujo secuencial...........................................- 40 - Figura 3.8. Región de expansión condicional con estructuras condicionales ...........................- 40 - Figura 3.9. Región de expansión condicional con estructuras iterativas...................................- 41 - Figura 3.10. Región de expansión condicional que termina debido a una instrucción dentro de ella. ............................................................................................................................................- 41 - Figura 3.11. Región de expansión condicional con procesamiento en paralelo (threads).........- 41 - Figura 3.12. Región de expansión condicional con una región de expansión condicional .......- 42 - Figura 3.13. Sintaxis sugerida por [STO04c] para los nodos de repetición. .............................- 42 - Figura 3.14. Estructura del diagrama de actividad para el modelado para las estructuras de control repetitivas. .................................................................................................................................- 43 - Figura 3.15. Regiones de expansión concurrentes. ...................................................................- 44 - Figura 3.16. Finalización del método debido a una instrucción en la región de expansión concurrente N. ...........................................................................................................................- 44 - Figura 3.17. Código en Java que crea y utiliza hilos.................................................................- 46 - Figura 3.18. Diagrama de actividad que corresponde al código de la figura 3.15 ....................- 47 - Figura 3.19. Relación del símbolo inicio del diagrama de actividad con el diagrama de clases. - 49 - Figura 3.20. Representación del método vacío..........................................................................- 49 - Figura 3.21. Representación del flujo secuencial de actividades. .............................................- 49 -

vi

Figura 3.22. Representación de una condición después del símbolo inicio. .............................- 50 - Figura 3.23. Representación de un ciclo de tipo while después del símbolo inicio. .................- 50 - Figura 3.24. Representación de la concurrencia después del símbolo inicio. ..........................- 50 - Figura 3.25. La conexión entre los símbolos inicio y concurrencia fin no es posible...............- 51 - Figura 3.26. Ejemplo de terminación inconsistente del modelo................................................- 51 - Figura 3.27. Representación de la lectura y escritura utilizando diagramas de actividad y pseudocódigo. ............................................................................................................................- 52 - Figura 4.1. Necesidad del diseñador..........................................................................................- 60 - Figura 4.2. Implementación del procedimiento.........................................................................- 62 - Figura 4.3. Métricas para la generación de código en el modelo de solución...........................- 62 - Figura 4.4. Diagrama de casos de uso de ADCODE.................................................................- 63 - Figura 4.5. Diagrama de secuencias de Generar Código..........................................................- 65 - Figura 4.5. Diagrama de secuencias de diagramar ....................................................................- 66 - Figura 4.7. Diagrama de clases de ADCODE ...........................................................................- 67 - Figura 4.8. Clases principales de la generación de código con diagramas de actividad. ..........- 68 - Figura 4.9. Código de ADCODE que procesa cada símbolo para la generación de código .....- 69 - Figura 4.10. Diagrama de actividad de una estructura IF_ELSE ..............................................- 70 - Figura 4.11. Pantalla de trabajo de ADCODE. .........................................................................- 71 - Figura 4.12 Símbolos dibujados por ADCODE que representan a los elementos terminales de la gramática. ..................................................................................................................................- 71 - Figura 4.13. Modelado de la estructura IF con ADCODE.......................................................- 72 - Figura 4.14. Modelado de la estructura IF_ELSE con ADCODE.............................................- 73 - Figura 4.15. Modelado de la estructura FOR con ADCODE....................................................- 73 - Figura 4.16. Modelado de la estructura WHILE con ADCODE ..............................................- 74 - Figura 4.17. Modelado de la estructura DO_WHILE con ADCODE........................................- 74 - Figura 4.18. Botón de generación de código Java a partir de diagramas de actividad..............- 75 - Figura 4.19. Métrica de complejidad ciclomática para diagramas de actividad........................- 75 - Figura 4.20. Cálculo de la complejidad ciclomática para código Java......................................- 75 - Figura 4.21. El cuadro de diálogo que muestra la medida de complejidad ciclomática. ..........- 75 - Figura 5.1. Casos de uso del caso de estudio: Cajero automático. [BJO04] .............................- 81 - Figura 5.2. Diagrama de clases del cajero automático. [BJO04] ..............................................- 82 - Figura 5.3. Código de la clase Card( ) obtenido de [BJO04]....................................................- 85 - Figura 5.4. Modelado y generación de código del método Card ( ) ..........................................- 85 - Figura 5.5. Modelado y generación de código del método getNumber( ).................................- 86 - Figura 5.6. Revisión de sintaxis con ECLIPSE.........................................................................- 87 - Figura 5.7. Pruebas de la ejecución del código .........................................................................- 87 - Figura 5.8. Código de la clase Status obtenido de [BJO04] ......................................................- 88 - Figura 5.9. Diagrama de actividad del método toString( ) ........................................................- 88 - Figura 5.10. Generación de código del método toString ( ) con ADCODE..............................- 89 - Figura 5.11. Revisión de sintaxis con ECLIPSE.......................................................................- 90 - Figura 5.12. Código de la clase Log obtenido de [BJO04] ......................................................- 91 - Figura 5.13. Diagrama de actividad del método Log ( )............................................................- 91 - Figura 5.14. Modelado y generación de código del método LogSend ( ) de la clase Log mediante ADCODE ..................................................................................................................................- 92 - Figura 5.15. Modelado y generación de código del método LogResponse ( ) de la clase Log mediante ADCODE...................................................................................................................- 92 - Figura 5.16. Revisión de sintaxis con ECLIPSE.......................................................................- 93 -

vii

Figura 5.17. Código de la clase CustomerConsole obtenido de [BJO04] .................................- 94 - Figura 5.18. Modelado y generación de código del método readPIN ( ) ..................................- 95 - Figura 5.19. Modelado y generación de código del método readMenuChoice( ) .....................- 96 - Figura 5.20. Modelado y generación de código del método readAmount( ).............................- 97 - Figura 5.21. Comprobación de sintaxis del código original en Eclipse ....................................- 98 - Figura 5.22. Comprobación de sintaxis del código generado por ADCODE del método readPin( )- 99 - Figura 5.23. Comprobación de sintaxis del código original con ECLIPSE del método readMenuChoice( ) ....................................................................................................................- 99 - Figura 5.24. Comprobación de sintaxis del código generado por ADCODE del método readMenuChoice() .....................................................................................................................- 99 - Figura 5.25. Comprobación de sintaxis del código original con ECLIPSE del método readAmount( ) .........................................................................................................................- 100 - Figura 5.26. Comprobación de sintaxis del código generado por ADCODE del método readAmount( ) .........................................................................................................................- 100 - Figura 5.27. Código de la clase Card ( ) obtenido de [BJO04]...............................................- 102 - Figura 5.28. Modelado con la herramienta ADCODE del método printReceipt( ).................- 102 - Figura 5.29. Generación de código con la herramienta ADCODE del método printReceipt(). - 103 - Figura 5.30. Comprobación de sintaxis del código original con ECLIPSE del método printReceipt( )..........................................................................................................................- 103 - Figura 5.31. Comprobación de sintaxis del código generado por ADCODE con ECLIPSE del método printReceipt( ).............................................................................................................- 104 - Figura 5.32. Valores obtenidos de la complejidad ciclomática...............................................- 106 - Figura A.1. Caso de Uso de modelar visualmente con ADCODE..........................................- 114 - Figura A.2. Caso de Uso Validar conexiones..........................................................................- 114 - Figura A.3. Cambiar propiedades de los elementos gráficos. .................................................- 115 - Figura A.4. Generación de código a partir de Diagramas de Actividad..................................- 115 - Figura A.5. Métrica de complejidad ciclomática ....................................................................- 115 - Figura A.6. Diagrama de paquetes ..........................................................................................- 115 - Figura A.7. Diagrama de clases de el diagramador de ADCODE ..........................................- 116 - Figura A.8. Diagrama de clases para el generador de código .................................................- 117 - Figura A9. Diagrama de clases del generador de código más detallado. ................................- 117 - Figura A.10. Diagrama de Estados de Elemento gráfico ........................................................- 118 - Figura A.11. Diagrama de actividad para los elementos gráficos ...........................................- 118 - Figura B.1. Propiedades del símbolo inicial............................................................................- 122 - Figura B.2. Propiedades del símbolo final ..............................................................................- 122 - Figura B.3. Selección del tipo de transición............................................................................- 122 - Figura B.4. Utilización del elemento gráfico transición..........................................................- 123 - Figura B.5. Propiedades del elemento gráfico Actividad........................................................- 123 - Figura B.6. Propiedades configurables del símbolo condicional ............................................- 123 - Figura B.7. Eliminar una transición. .......................................................................................- 124 - Figura B.8. Mensaje de código generado con éxito ................................................................- 124 - Figura B.9. Mensaje de error en la generación del código......................................................- 124 -

viii

Índice de Tablas Tabla 1.1. Tabla comparativa de la generación de código a partir de diagramas de actividad ...- 6 - Tabla 1.2. Herramientas de modelado UML. Tomada de [QUI05] ............................................- 9 - Tabla 2.1. OCL aplicado en diagramas de UML.......................................................................- 21 - Tabla 2.2. Métricas aplicadas a diagramas UML ......................................................................- 28 - Tabla 3.1. Reglas de producción que permiten transformar los diagramas de actividad a código de las estructuras básicas................................................................................................................- 37 - Tabla 3.2. Mapeo de procesamiento concurrente a diagramas de actividad .............................- 47 - Tabla 3.3. Conexiones de los elementos visuales de los diagramas de actividad. ....................- 48 - Tabla 4.1. Escenario de CU1_Diagramar. .................................................................................- 63 - Tabla 4.2. Escenario de CU2_GenerarCódigo. .........................................................................- 64 - Tabla 4.3. Tabla de transiciones ................................................................................................- 70 - Tabla 4.4. Elementos que integran la herramienta ADCODE...................................................- 72 - Tabla 5.1. Casos de prueba definidos para la herramienta ADCODE ......................................- 83 - Tabla 5.2. Valores obtenidos para la medida de la complejidad ciclomática............................- 86 - Tabla 5.3. Valores obtenidos para la medida de la complejidad ciclomática............................- 89 - Tabla 5.4. Valores de prueba para la función toString ( ) .........................................................- 90 - Tabla 5.5. Valores obtenidos para la medida de la complejidad ciclomática............................- 93 - Tabla 5.6. Valores de prueba para la clase Log ( ) ....................................................................- 93 - Tabla 5.7. Valores obtenidos para la medida de la complejidad ciclomática............................- 98 - Tabla 5.8. Valores de prueba para la clase Customer Console ( ) ...........................................- 101 - Tabla 5.9. Valores obtenidos para la medida de la complejidad ciclomática..........................- 103 -

ix

Glosario de términos ADCODE Herramienta prototipo que permite generar código orientado a objetos de

las estructuras básicas de secuenciación, repetición y selección a partir de diagramas de actividad UML.

CENIDET Centro Nacional de Investigación y Desarrollo Tecnológico InverDDVi Es una herramienta prototipo desarrollada en CENIDET que utiliza un

modelo de ingeniería inversa para la obtención de diseño detallado en diagramas de Warnier basado en Leviss para código C. Pertenece a la suite MANGO.

Inverjava Realiza ingeniería inversa a partir de código Java para la obtención de los diagramas de clases. Pertenece a la suite MANGO.

InverS3C Herramienta prototipo desarrollada en CENIDET que permite obtener los diagramas de secuencias del código en lenguaje C++. Pertenece a la suite Mango.

InverSOODA Herramienta prototipo desarrollada en CENIDET que realiza ingeniería inversa de código fuente en C++ para obtener el diseño de diagramas de clases y Warnier.

Ke2 Diagramador de diagramas de estados que mantiene la consistencia con los diagramas de clases.

LEVISS Es un generador de código para leguaje C utilizando diagramas de Warnier para el diseño detallado de funciones desarrollado en CENIDET.

MANGO Ambiente de desarrollo orientado a objetos elaborado en CENIDET. Por el grupo de ingeniería de software.

OMG Object Management Group (de sus siglas en inglés Grupo de Gestión de Objetos) es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos.

PARCU (perfil para la adquisición de requerimientos centrados en el usuario). Consiste en la definición e implementación de un perfil de UML para la adquisición de requerimientos. Pertenece a la suite Mango.

Redes de Petri Las redes de Petri son consideradas una herramienta para el estudio de los sistemas que permiten modelar el comportamiento y la estructura de un sistema, y llevar el modelo a condiciones límite, que en un sistema real son difíciles de lograr o muy costosas.

SADUC Diagramador de casos de uso de UML. SOODA Modelado visual orientado a objetos de los diagramas de clases. UML Lenguaje de Modelado Unificado. Es un lenguaje gráfico para visualizar,

especificar, construir y documentar un sistema de software. XML Lenguaje de marcado extensivo. XMI XML de Intercambio de Metadatos (por las siglas en ingles de Metadata

Interchange)

x

Resumen El objetivo del presente trabajo de tesis es la generación de código a partir de diagramas de actividad UML y para lograrlo se estableció una forma de analizar la sintaxis de los diagramas de actividad mediante un diagramador. El diagramador permite la construcción de diagramas de actividad y la conexión de los elementos gráficos se rigen mediante una gramática visual la cual establece las reglas para la conexión de los elementos del diagrama y para la generación de código. La gramática visual es creada en éste trabajo de investigación y representa una manera de formalizar los diagramas de actividad además de la formalización existente basada en redes de Petri. Los elementos gráficos de los diagramas de actividad permiten modelar estructuras de control que pueden ser transformadas a código siguiendo reglas de las regiones de expansión que representan los conjuntos de instrucciones agrupadas dentro de un bloque. El diagrama de actividad y el código generado a partir de los diagramas de actividad deben tener correspondencia. Se realizaron pruebas de escritorio que permitieron comparar la transformación manual y automática del diagrama de actividad así como el orden de ejecución de las instrucciones, también se midió la complejidad ciclomática en diagramas de actividad y del código fuente de un modelo de un sistema de un cajero automático [BJO04] del cual se modelaron algunos métodos de las clases que lo integran. Los métodos seleccionados contienen estructuras de control secuencial, repetitivo y de selección. También se realizaron pruebas sobre la lógica del modelo realizado en el diagrama de actividad y el código generado automáticamente y además se verificó la sintaxis del código generado automáticamente mediante el IDE de desarrollo ECLIPSE. Las pruebas reflejaron que se puede comparar un número (que representa la complejidad ciclomática) obtenido del modelo contra el número obtenido del código, ése número representa sólo que la cantidad de condicionales (base de las estructuras repetitivas) en uno y otro es el mismo pero no asegura que el código generado sea funcional sólo que existe correspondencia entre las estructuras del modelo y las del código.

xi

Abstract The objective of this thesis is the code generation from UML activity diagrams, to achieve that objective, is established one way to analyze the activity diagram’s syntax by means a diagrammer. The diagrammer allows the activity diagram’s construction, and the connexion of all the graphic elements it’s controlled with a visual grammatical. The graphic elements of the activity diagrams allows develop of the control structures that can be transformed to code following the expansion region rules, those regions represents the instructions set grouped inside a box. Activity diagrams and the generated code from those activity diagrams must be equivalents. To measure those equivalency the activity diagrams and source code of an automatic cashier system [BJO04] ciclomatic complexity was obtained. From the automatic cashier system only some methods were seleccioned, those methods that haves sequential control structures, repetitive and for selection. Also were performed test about the logic of the model inside the activity diagram and the automatic generated code. Finally the automatic generated code syntax was verified with the develop IDE ECLIPSE. All the tests shows that comparing the mode’s ciclomatic complexity and the code’s ciclomatic complexity only can be probed the equality between control structures and not ensures the code’s functionality.

xii

Hoja en Blanco

CAPÍTULO 1 En este capítulo se describirán los siguientes aspectos: 11 Introducción 1.2 Antecedentes 1.3 Trabajos relacionados 1.4 Descripción del problema 1.5 Objetivo 1.6 Justificación 1.7 Beneficios 1.8 Pregunta de investigación 1.9 Alcances y limitaciones

Introducción

Capítulo 1. Introducción y antecedentes de la investigación

- 2 -


1.1. Introducción Los analistas de software son responsables de traducir las especificaciones de los requerimientos del cliente y proveer los diseños de sistemas de software. Para modelar sistemas de software el OMG (por sus siglas en inglés Object Management Group) [OMG06] ha propuesto un estándar de integración de desarrollo llamado Lenguaje de Modelado Unificado (UML por sus siglas en inglés Unified Modeling Language), el cual actualmente se encuentra en su versión 2.0, el estándar está integrado por diagramas que permiten modelar los aspectos estáticos y dinámicos de los sistemas de software.

Los aspectos dinámicos corresponden al flujo de control, los diagramas de actividad sirven para modelar éste tipo de aspectos y pueden utilizarse para visualizar, especificar, construir y documentar la dinámica de una sociedad de objetos. Según [STO04c] la notación de los diagramas de actividad es apropiada para el modelo de procesos de negocio, flujos de trabajo, modelado de los métodos de las clases, modelado del comportamiento a nivel de sistema y modelado de servicios Web.

El presente trabajo utiliza los diagramas de actividad para el modelado de los métodos de

las clases y se enfoca en la generación de las estructuras básicas de secuenciación, selección y repetición para código orientado a objetos a partir de diagramas de actividad UML. Esta investigación enriquece las investigaciones realizadas para el ambiente de desarrollo Mango pero la herramienta no está integrada al ambiente. Mango es un ambiente de desarrollo que hace uso de ingeniería directa a partir de diagramas o ingeniería inversa a partir de código fuente y se trabaja sobre él en el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET).

Los diagramas de actividad tienen una notación muy amplia, el estándar incluso según

[STO04a] no contiene un lenguaje concreto para las etiquetas de los símbolos de los diagramas de actividad o para las expresiones protegidas. En la presente investigación se utilizan sólo los elementos de la notación que permiten modelar las estructuras básicas de control (inicio, fin, actividad, condicional, transición y merge), éstos elementos seleccionados se pueden relacionar entre sí mediante las producciones de una gramática visual relacional (la gramática se explica en el capítulo 3).

La investigación acerca de la generación de código a partir de diagramas no es algo

novedoso algunas herramientas como Rational Rose [RAT06], Together [TOG06], Poseidón [POS06] y Enterprise Architect [ENT06] ya generan código al menos de los diagramas de clases UML y se han apoyado en lenguajes formales como OCL para agregar más precisión a las especificaciones de los modelos. Existen investigaciones que tratan de formalizar la semántica de los diagramas de actividad; trabajos como [STO04a], [STO04b], [STO04c], y [ESH04a] realizan mapeos hacia las redes de Petri y redes de Petri coloreadas, para expresar flujos de datos y flujos de trabajo. Las redes de Petri permiten expresar los procesos que requieren sincronía (como el software embebido). En éste capítulo más adelante se analizan algunos trabajos sobre generación de código a partir de diagramas de actividad. El presente trabajo utiliza la investigación de [STO04c] sobre flujos de control.

Generación de código a partir de diagramas de actividad UML

- 3 -

El capítulo 1 describe las investigaciones realizadas acerca de la generación automática de código a partir de diagramas de actividad. Esta integrado por los antecedentes: representados por el entorno de desarrollo MANGO, los trabajos relacionados: que se refieren a las herramientas e investigaciones de modelado y de generación de código a partir de diagramas de actividad.

El capítulo 2 presenta algunos conceptos necesarios para entender mejor la solución

propuesta en ésta investigación, el lenguaje de modelado unificado (por sus siglas en inglés, UML), los elementos gráficos que comprenden los diagramas de actividad y su aplicación. La relación entre los elementos gráficos definida mediante una gramática visual, las métricas que se aplicaron para establecer un punto de comparación entre el diagrama de actividad y el código generado en ésta investigación.

El capítulo 3 contiene la solución. La forma en cómo se atacó el problema de la

codificación de diagramas de actividad, las reglas de codificación y las conexiones de los elementos gráficos que podrían afectar el flujo de control en la codificación (existencia de instrucciones que provocaran errores en la generación automática). Además en éste capítulo se describe en éste capítulo la gramática visual generada.

El capítulo 4 se refiere a la automatización del procedimiento de generación de código

mediante el desarrollo de una herramienta. La herramienta verifica la construcción del diagrama automáticamente, valida la gramática visual al momento de la inserción de un nuevo símbolo, utiliza las reglas de producción definidas en la gramática para la generación de código, identifica las estructuras de control en el diagrama en el momento de la generación automática y permite calcular la complejidad ciclomática del diagrama de actividad y del código fuente.

El capítulo 5 corresponde al plan de pruebas de la herramienta y está basado en el

estándar de pruebas 829 de la IEEE (El estándar IEEE 829-1983 describe los tipos de documentos que pueden producirse durante el proceso de prueba) [IEEE98]. Para las pruebas se utilizó el modelado de un sistema de un cajero automático [BJO04] tomando algunos métodos de las clases que tuvieran estructuras de control. A los métodos utilizados se les llamó casos de prueba (CP) y al desarrollo de las pruebas se le llamó especificación de los procedimientos de prueba (EP).

Y por último el capítulo 6 corresponde al análisis del resultado de las pruebas con el caso

de estudio del cajero, las conclusiones del trabajo de investigación, beneficios y trabajos futuros que podrían realizarse.

1.2. Antecedentes En el CENIDET, el grupo de ingeniería de software ha elaborado un ambiente de desarrollo de software orientado a objetos que ha sido denominado Mango. Este proyecto se centra en el UML, el cual pretende apoyar al desarrollo de software orientado a objetos a través del modelado de los aspectos dinámicos y estáticos del sistema. El ambiente de desarrollo permite realizar ingeniería directa e inversa para código C++ y JAVA. (Ver arquitectura en Figura 1). Los diagramas UML que utiliza son:

• Casos de uso: SADUC.


- 4 -

• Clases: SOODA. • Warnier: DDVi. • Estados: Ke2. • Paquetes: Ppkg. • Secuencias: S3C.

La figura 1.1 corresponde a la arquitectura de la suite desarrollada en el CENIDET y nombrada como MANGO [ALF06] con ella se trata de modelar sistemas basándose en la especificación UML y los diagramas de Warnier automatizando la generación de código a partir de diagramas modelados. En ella se puede observar que la arquitectura de MANGO se compone de siete diseñadores para los diferentes diagramas UML y los diagramas de Warnier (diagrama de casos de uso, diagrama de clases, diagramas de Warnier, diagrama de estados, diagrama de paquetes, diagrama de secuencias y diagramas de actividad). Cada diseñador es un diagramador que permite modelar su correspondiente diagrama. El diseñador SADUC es utilizado como apoyo del perfil para la adquisición de requerimientos centrados en el usuario (PARCU). La investigación de PARCU permite modelar con una herramienta de mapas mentales los requerimientos del cliente y transformar el mapa mental resultante en un diagrama de casos de uso diseñado en la herramienta SADUC. El diseñador de clases SOODA es la base para el desarrollo de investigaciones basadas en los diagramas de clases donde se modelan los diagramas de clases mediante una herramienta diagramadora y se obtiene el código en JAVA o C++ (ingeniería directa), o a partir de código fuente generar el diagrama de clases en SOODA (ingeniería inversa). El diseñador de diagramas de Warnier permite realizar el diseño detallado de los métodos de las clases mediante diagramas de Warnier y permite generar el código fuente a partir de los diagramas o generar el diagrama de Warnier a partir del código fuente. El diseñador de actividades (ADCODE, herramienta originada a partir de la presente investigación) permite realizar el modelado de los métodos de las clases y modelar con diagramas de actividad las estructuras de control además generar código a partir de los diagramas de actividad.


- 5 -

Figura 1.1. Arquitectura de Mango [ALF06].

La figura 1.2, representa la evolución que ha tenido la suite desde 1997, esta información se tomó de [ALF06].

1997 2008

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008

Figura 1.2. Evolución de Mango [ALF06].

1997 LEVISS. Es un generador de código para leguaje C utilizando diagramas de Warnier

para el diseño detallado de funciones [MAR97]. 2000 SOODA y DDVi. Modelado visual orientado a objetos. Utiliza los diagramas de

clases junto con los diagramas de Warnier para la generación de código C++. [PAR00]. 2002 InverDDVi. Utiliza un modelo de ingeniería inversa para la obtención de diseño

detallado en diagramas de Warnier basado en Leviss para código en lenguaje C [WEN02].


- 6 -

2003 InverSOODA. Realiza ingeniería inversa de código fuente en C++ para obtener el diseño de diagramas de clases y Warnier [HER03].

2004 Ppkg es el diagramador de paquetes [VAL04], Ke2 diagramador de estados

[GON04], S3C es un diagramador de secuencias [MAC04], SADUC diagramador de casos de uso con soporte de informes [CAB04] InverJava que hace ingeniería inversa de diagramas de clases y Warnier a partir de código Java [NUÑ04].

2006 InverS3C. Obtiene los diagramas de secuencias a partir código escrito en C++.

[ALF06]. 2007 PARCU (perfil para la adquisición de requerimientos centrados en el usuario).

Consiste en la definición e implementación de un perfil de UML para la adquisición de requerimientos funcionales centrados en el usuario. [ALB07]. ADCODE (Activity Diagrams to Code), es el nombre de la herramienta que se obtuvo con la presente investigación. La cual permite modelar los métodos de las clases con diagramas de actividad UML y generar código en Java de las estructuras básicas de secuenciación, repetición y selección a partir del modelo.

1.3. Trabajos relacionados Existen diferentes investigaciones acerca de la generación de código a partir de diagramas de actividad, los cuales sirven para modelar diferentes aspectos cómo los procesos de negocio, métodos de las clases, etc. Estas investigaciones tratan de asegurar la consistencia mediante el uso de la combinación de uno o más diagramas adicionales al diagrama de actividad. La tabla 1.1 muestra qué se ha hecho al respecto. La columna 2 (modela) se refiere al tipo de modelado que se realiza con los diagramas de actividad debido a que se puede modelar procesos de negocio, sistemas de software, métodos de las clases, etc. La columna 3 (Diagramas asociados) corresponde a los diagramas UML además del diagrama de actividad, que están relacionados en el proceso de generación de código. La comuna 4 (lenguaje generado) es el lenguaje que es generado a partir de la investigación. El lenguaje asociado corresponde al texto contenido en las etiquetas o símbolos de los diagramas de actividad. La última fila corresponde a la presente investigación.

Tabla 1.1. Tabla comparativa de la generación de código a partir de diagramas de actividad

REFERENCIA MODELA DIAGRAMAS ASOCIADOS

LENGUAJE GENERADO

LENGUAJE ASOCIADO DESCRIPCIÓN

[TAK06] Procesos de negocio DA +DC Ninguno OCL

Propuso el uso de OCL para describir y modelar procesos de negocios. Hizo una extensión de OCL para lograr el modelado de procesos de negocio.

[TRO03] Sistemas de software

DA+DC +DCOL Java Java

Describió cómo a partir de diagramas de colaboración se genera un diagrama de actividad parcial, al que se le agrega información adicional. El código generado es de flujo secuencial.


- 7 -

[GAL05] Procesos de negocio DA+DC XPDL XPDL

Realizó un mapeo de tipos de datos básicos de UML en tipos de datos básicos del esquema del Lenguaje para la Definición de Flujo de trabajo (XPDL). El código generado es la entrada para el motor reflujo de trabajo utilizado por su propia herramienta.

[ZUN01] Cuerpos de los métodos DA Java Java

Planteó la generación de código a partir de diagramas de actividad. Los diagramas de actividad utilizan bloques de código Java.

[RHA06] Sistemas embebidos DC+DA C++ C, C++

Para generar código en ésta herramienta debe configurar la propiedad CPP_G::OPERATION::ActivityReferenceAttributes a TRUE. Existen colisiones con los nombres de los atributos de las clases y los argumentos modelados en la operación. No soporta diagramas de herencia en el caso de una operación que sobrescribe una operación modelada. Operaciones globales con diagramas de actividad no son soportadas.

ADCODE Cuerpos de los métodos DA Java Java

Genera código de las estructuras básicas, e implementa métricas de complejidad ciclomática para la comparación entre los diagramas de actividad y el código generado.

Las investigaciones de la tabla 1.1 representan lo que se ha hecho en cuanto a generación de código a partir de diagramas de actividad. Y se observa que ninguna valida la generación de código a partir de los diagramas de actividad como lo hace la presente investigación. Las siguientes investigaciones contribuyeron al proceso de solución del presente trabajo de investigación.

Sistema visual para el diseño detallado de métodos de clases con UML (SIDDOO): es un prototipo que surgió a partir de una tesis elaborada en el CENIDET. Es una herramienta prototipo implementada en Java 1.3. Permite modelar el diseño detallado de los métodos de un sistema orientado a objetos utilizando los diagramas de actividad. Realiza la validación del modelo mediante una gramática posicional restringida para los diagramas de actividad, permite modelar como máximo tres líneas de sincronización. Primero necesita contar con la conceptualización de los métodos de las clases antes de iniciar el modelado. No genera código fuente a partir de los diagramas de actividad [CAS03].

De ésta investigación se obtuvo que el utilizar la gramática posicional no era la mejor

opción para modelar los diagramas de actividad debido a que la gramática posicional restringe la ubicación de un componente visual con respecto a otro y sólo se puede conectar un elemento con otro en posiciones izquierda, derecha, arriba o abajo. La gramática visual relacional utilizada en la presente investigación se enfoca en que elemento se conecta con otro.

Converting statecharts into Java code. Este trabajo presenta la implementación de un

modelo que transforma diagramas de estados en código orientado a objetos en lenguaje Java. Trabaja con la jerarquía de estados, estados concurrentes, branch, guard, join, fork y la


- 8 -

composición de estados. También implementan eventos de tiempo con una clase llamada Timer. [ALI99]. Ésta investigación aportó una idea acerca del posible mapeo que podía realizarse a partir de los elementos visuales de un diagrama.

UMT: Es una herramienta de transformación de modelos y generación de código basada

en especificaciones de modelos UML y XMI. Permite insertar nuevos generadores en XSLT o JAVA. El ambiente es implementado en JAVA. [UMT06]. La idea de generación de código a partir del XMI de los diagramas que proporciona ésta herramienta es atractiva y sirvió para analizar la posibilidad de generar el código a partir del XMI de los diagramas de actividad pero se descartó cuando se llegó a la conclusión de que se expandía la presente investigación en la definición de un perfil XMI que permitiera modelar las estructuras de control el cual no era el tema central de la presente investigación.

FUJABA (Acrónimo de From UML to Java And Back Again). Herramienta desarrollada que surge a partir de una tesis en la Universidad de Paderborn, Alemania. Utiliza diagramas históricos para la especificación de los aspectos dinámicos. Estos diagramas son la combinación de diagramas de actividad y de colaboración. Utiliza un parser para construir un gráfico de sintaxis del código fuente. FUJABA puede proporcionar ayuda para el reconocimiento, creación y terminación de los patrones de diseño [FUJ06]. De ésta investigación se aprendió el uso de diagramas históricos que son la combinación de diagramas de colaboración y diagramas de actividad. Pero no se utilizaron en la solución del presente trabajo de investigación debido a que MANGO no contaba con un diseñador de diagramas de colaboración.

Las herramientas comerciales que se analizaron se encuentran en la tabla 1.2 [QUI05] donde se observa que la versión UML que utilizan las herramientas varía desde la 1.3 hasta la 2.0 (ver versión de UML en la cuarta fila). En la sexta fila se encuentra el tipo de intercambio de archivos que se realiza en la herramienta, el intercambio de archivos permite la edición de los diagramas en una herramienta diferente a la que los originó y es realizado en su mayoría mediante el XMI (por las siglas en ingles de Metadata Interchange, que se traduce como XML de Intercambio de Metadatos). Las herramientas generan código en varios lenguajes pero solo del enfoque estructural, es decir, generan el esqueleto del código de la aplicación, normalmente a partir de los diagramas de clases (ver generación de código a partir de diagramas en la última fila), las herramientas CASE que soportan la generación de código para diagramas de clases solo generan el código estructural que incluye declaraciones de variables y métodos de las clases. Se hace énfasis en el intercambio de archivos XMI como una opción para generar código a partir del XMI del diagrama de actividad. Se observa que las herramientas comerciales de la tabla no contienen generación de código a partir de diagramas de actividad.


- 9 -

Tabla 1.2. Herramientas de modelado UML. Tomada de [QUI05]

Propiedades / Herramienta

RATIONAL ROSE

www.rational.com

WithClass

http://www.microgold.com/

TOGETHER

www.borland.com

POSEIDON

www.gentleware.com

RHAPSODY

http://www.ilogix.com

ENTERPRISE

ARCHITECTURE

http://www.sparxsystems.com

Observaciones Generales

Es una de las herramientas más usadas. Permite la

especificación, visualización

construcción y documentación del

sistema de software.

Utiliza la perspectiva del objeto relacional con

diferentes metodologías de desarrollo y modelado.

Se basa en la consideración de que

los modelos de aplicación y

arquitectura son independientes uno del

otro.

Genera código en Java usando plantillas. Apoya el

proceso de documentación de diagramas con UML doc.

Herramienta de modelado UML que permite una vista global del proyecto. Y que

apoya la generación de código.

Herramienta que soporta Model Driven Architecture (MDA).

Apoya la generación de código.

Plataforma Sistema operativo

Windows 98,98SE, ME, NT 4.0, XP

Sistema operativo Windows.

Independiente de plataforma. Requiere máquina virtual de Java 1.3 o superior.

Independiente de plataforma. Requiere máquina virtual de

Java 1.3 o superior.

Windows 2000/XP Red Hat Enterprise Linux v3.0/4.0

Sistema operativo Windows 98,98SE, ME, NT 4.0, XP

Versión de UML UML 1.3 UML 1.3 UML 1.1, 1.3, 1.4 UML 2.0 UML 2.0 UML 2.0

Apoyo a lenguajes formales

OCL No hay apoyo a lenguajes formales OCL OCL Lenguajes específicos del

dominio OCL

Intercambio de archivos XMI no genera XMI XMI, JDBC XMI, compatibilidad con

Rational Rose XMI XMI

Autogeneración

Java, J2EE, ANSI c++, Visual C++, VB, Corba IDL, MIDL y

XML

C++, C#, Java, Delphi, VB, VB.NET

VB, VB.NET, CORBA IDL, C++,

Java, HTML, C++ y XML, Plugins para C#, CORBA

IDL. C, C++, Java, Ada C++, C#, Java, Delphi, VB.Net,

Visual Basic, ActionScript y PHP

Generación de código a partir de diagramas

Clases Clases Clases, secuencias Clases Clases, estados Clases


- 10 -

1.4. Descripción del problema Los defectos detectados en la etapa de compilación representan un porcentaje muy alto del total de defectos removidos por etapa [SAN06]. Estos defectos son introducidos en las etapas previas a la compilación y tienen un costo de eliminación en tiempo más alto que en etapas tempranas de desarrollo.

El problema consiste en que: la codificación a partir de los diagramas de actividad de un sistema orientado a objetos y modelado con UML se realiza de forma manual, haciéndola susceptible a defectos, provocando inconsistencias entre el modelo y el código.

1.5. Objetivo El objetivo es:

• Diseñar un procedimiento de transformación de un diagrama de actividad a código de las estructuras básicas de secuenciación, repetición y selección.

1.6. Justificación En un caso real, el proyecto SIGEFI que fue construido por un grupo de diez programadores en 18 meses de desarrollo se tuvo que:

“En revisión de código y diseño se eliminan el 29% de los defectos, pero en pruebas y compilación se eliminan el 64%. Si la relación fuera al revés, digamos, 64% en revisiones y 29% en compilación y pruebas, el proceso sería igual de efectivo en términos de defectos pero no en términos de tiempos, ya que eliminar un defecto en pruebas nos consume mucho más tiempo que hacerlo en otras etapas tempranas.” Ver figura 1.3. [SAN06]


- 11 -

Figura 1.3. Porcentaje de defectos removidos por etapa.

Lo anterior indica que el porcentaje de eliminación de defectos y el costo en tiempo son

altos en las etapas de revisión de código, compilación y prueba de unidades. Herramientas de modelado como Rational Rose [RAT06], Together [TOG06], Poseidón

[POS06] y Enterprise Architect [ENT06] no realizan la generación de código a partir de diagramas de actividad. Esta escasez de opciones para obtener de manera automática el código de diseño detallado de un sistema, en específico aquel que involucra las estructuras básicas, hace necesario que se lleven a cabo trabajos en dirección de la solución de ésta deficiencia.

1.7. Beneficios Los beneficios que se obtuvieron al generar código orientado a objetos a partir de diagramas de actividad consisten en que: la interpretación de los diagramas de actividad no se haga de forma apreciativa sino que se sustente por una serie de reglas y de equivalencias de los diagramas de actividad a código, esperando reducir el número de defectos debidos a una mala interpretación de estos diagramas.

1.8. Pregunta de investigación Para el diseño que involucra las estructuras básicas de secuenciación, repetición y selección de los diagramas de actividad, se propone la siguiente pregunta de investigación:

¿Es posible generar código de las estructuras básicas de manera automática a partir de los diagramas de actividad UML?


- 12 -

1.9. Alcances y limitaciones

1.9.1. Alcances

• Se identificaron las estructuras básicas de secuenciación repetición y selección. • Se obtuvo una especificación de la equivalencia de los componentes de los diagramas de

actividad y el código que representan. • Se obtuvo una herramienta que implementa y automatiza el procedimiento para la

generación de código a partir de los diagramas de actividad.

1.9.2. Limitaciones • El código generado sólo es el de las estructuras de secuenciación básicas, repetición y

selección • No se modificaron los archivos de las demás herramientas que conforman MANGO. • No se evaluó que el diagrama estuviese sintácticamente correcto. • Genera código sólo para lenguaje Java.


- 13 -

CAPÍTULO 2 En este capítulo se describirán los siguientes aspectos: 2.1 Introducción 2.2 Modelado 2.3 Lenguaje de Modelado Unificado 2.4 Descripción de los diagramas de actividad 2.5 Elementos contenidos en los diagramas de actividad 2.6 Lenguajes visuales 2.7 Generación de código a partir de diagramas de actividad 2.8 Métricas de los diagramas UML 2.9 Conclusiones del capítulo

Marco Conceptual

Capítulo 2. Marco Conceptual

- 14 -

Capítulo 2. Marco conceptual

2.1. Introducción En la solución de del problema de generación de código a partir de diagramas se utilizaron conceptos como: lenguajes visuales, diagramas de actividad, métricas para diagramas UML y programación orientada a objetos. Es necesario conocer éstos conceptos para entender mejor la solución planteada en el capítulo siguiente. La figura 2.1 muestra la relación de los conceptos descritos anteriormente en forma de diagrama de Venn.

Figura 2.1. Relación de los conceptos del marco conceptual

En la figura 2.1 se observa que los diagramas de actividad pertenecen al UML que a su vez sirve para realizar el modelado de los sistemas de software. Los diagramas de actividad son utilizados para modelar estructuras de control mediante una gramática visual relacional de los lenguajes visuales. Las estructuras de control modeladas son transformadas a código fuente orientado a objetos. Y la transformación es evaluada mediante métricas que se puedan aplicar en diagramas de UML y código fuente.

2.2. Modelado Los modelos [PRE02b] ayudan a entender la entidad que se va a construir. Cuando la entidad está representada por software ésta modela la información que transforma el software, las funciones que permiten que ocurran las transformaciones y el comportamiento del sistema cuando estas ocurren. Los modelos creados durante el análisis de requisitos tienen papeles muy importantes:

• Ayudan al analista a entender la información de cómo funciona y se comporta el sistema. • Es un punto de partida para la revisión, consistencia y precisión de la especificación de

los requerimientos. • Es fundamental para el diseño, proporcionan al diseñador una representación del software

que se trasladará a la implementación.

Lenguajes visuales

Programación Orientada a Objetos

Modelado

UML

Diagramas de actividad

Generación de código a partir de Diagramas de

Actividad

Métricas para diagramas UML


- 15 -

2.2.1. Diseño y la técnica de modelado Para elaborar sistemas de software y hardware el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando la notación precisa, verificar esos modelos y añadir poco a poco detalles que transformen esos modelos en implementaciones. El hacer modelos de sistemas de software tiene varios objetivos:

• Probar una entidad antes de construirla. • Comunicar al cliente un bosquejo del comportamiento del sistema. • Visualizar el sistema antes de implementarlo. • Reducir la complejidad para poder entender mejor el sistema a través del modelo.

La Técnica de Modelado a Objetos (OMT) combina tres aspectos para modelar un sistema de

software: 1. El modelo de objetos representa los aspectos estáticos y la estructura de los objetos

del sistema (relaciones entre objetos, atributos y operaciones). 2. El modelado dinámico representa los aspectos temporales y secuencia de operaciones

del sistema. 3. El modelado funcional representa las transformaciones de funciones del sistema

(dependencias entre los valores y cálculo de salida a partir de los valores de entrada).

2.2.2. Relaciones entre modelos

Cada modelo de la OMT contiene referencias a los demás modelos del sistema de software, el modelo de objetos describe las estructuras de datos sobre las cuales trabajan los otros dos modelos, sus operaciones tienen correspondencia con sucesos en el modelado dinámico y con funciones del modelo funcional. El modelo dinámico describe la estructura de control de los objetos y las acciones que modifican valores e invocan funciones. Por último, el modelo funcional describe las funciones que fueron invocadas por operaciones en el modelo de objetos y acciones en el modelo dinámico. [RUM96]

Para generar código a partir de diagramas de actividad se deben considerar los modelos de

la OMT descritos anteriormente. El modelo estático representado por los diagramas de clases y los modelos dinámico y funcional representados por los diagramas de actividad.

2.3. Lenguaje de modelado unificado UML

“… es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. UML proporciona una forma estándar de escribir los planos de un sistema, cubriendo tanto las cosas conceptuales, tales como procesos de negocio y funciones de un sistema, como las cosas concretas, tales como las clases escritas en un lenguaje de programación específico, esquemas de bases de datos y componentes de software reutilizable” [BOO99a].


- 16 -

Según [UML06] UML no es un lenguaje de programación, pero los modelos que lo integran se pueden asociar de forma directa a lenguajes de programación, definiendo una correspondencia entre un diagrama de UML y un lenguaje de programación como C++, Java, C# o Visual Basic.

2.3.1. Modelado estático En un sistema de software el modelado de los aspectos estáticos de un sistema incluyen la existencia y ubicación de clases, interfaces, colaboraciones, componentes y nodos. El modelado estático se lleva a cabo a través de los cuatro diagramas estructurales de UML, los cuales existen para visualizar, especificar, construir y documentar los aspectos estáticos de un sistema de software.

Según [BOO99b] los diagramas que componen el modelado estático son: 1. Diagramas de clases que representan un conjunto de clases y las relaciones entre

ellas. 2. Diagramas de objetos que representan un conjunto de objetos y sus relaciones. 3. Diagramas de componentes que Representan los componentes y las relaciones entre

ellos, se relacionan con los diagramas de clases. Un componente normalmente corresponde con una o más clases, interfaces o colaboraciones.

4. Diagramas de despliegue muestran un conjunto de nodos y sus relaciones.

2.3.2. Modelado dinámico Según [BOO99b] el modelado dinámico de un sistema de software se entiende como el modelado de estado y el comportamiento de objetos. Los aspectos dinámicos del sistema involucran el flujo de mensajes a lo largo del tiempo y el movimiento físico de componentes en una red.

Los diagramas que componen el modelado dinámico son: 1. Diagramas de caso de uso los cuales organizan el comportamiento del sistema. 2. Diagramas de estados se centran en el estado cambiante de un sistema dirigido por

eventos. 3. Diagramas de interacción son similares a los diagramas de Gantt y se centran en los

objetos (recursos) que juegan alguna actividad a lo largo del tiempo. Muestran objetos que pasan mensajes. Estos agrupan a los diagramas de secuencia y de colaboración.

4. Diagramas de secuencia destacan la operación temporal de los mensajes que se pueden enviar entre los escenarios que involucran la interacción de ciertos objetos interesantes.

5. Diagramas de colaboración destacan las relaciones estructurales entre los objetos que interactúan.

6. Diagramas de actividad permiten describir la secuencia de las actividades del sistema. Son una forma especial de diagramas de estado, que únicamente (o mayormente) contienen actividades.


- 17 -

2.4. Descripción de los diagramas de actividad Los diagramas de actividad se utilizan para el modelado de los aspectos dinámicos de los sistemas de software, se usan para construir sistemas ejecutables a través de ingeniería directa o inversa [BOO99c]. El diagrama de actividad:

• Es fundamentalmente un diagrama que muestra el flujo de control entre actividades. • Se puede modelar el flujo de un objeto conforme pasa de estado a estado en diferentes

puntos del flujo de control. • Puede utilizarse para visualizar, especificar, construir y documentar la dinámica de

una sociedad de objetos y para modelar el flujo de control de una operación. • Gráficamente un diagrama de actividad es una colección de nodos y arcos el cual tiene

características de las máquinas de estados, puede contener estados simples y compuestos, bifurcaciones, divisiones y uniones.

Los diagramas de actividad contienen:

• Estados de actividad o estados de acción. • Transiciones. • Objetos.

2.5. Elementos contenidos en los diagramas de actividad Los elementos gráficos contenidos en los diagramas de actividad permiten modelar las estructuras de control utilizando los símbolos inicio, actividad, bifurcación, transición y fin. En [BOO99c] se definen esos elementos como sigue a continuación:

Acción: Está compuesta de instrucciones atómicas ejecutables que producen un cambio en el estado de un sistema o la devolución de un valor. Las acciones incluyen llamadas a otras operaciones, envío de señales, creación o destrucción de objetos o simples cálculos como la evaluación de una expresión.

Actividad: Es una ejecución no atómica en curso dentro de una máquina de estados, las actividades producen finalmente una acción. Un diagrama de actividad de perspectiva puede ser de dos tipos: el tipo uno es de especificación y el tipo dos es de implementación. Una actividad es un método sobre una clase, se representa por un rectángulo con las puntas redondeadas en cuyo interior se representa una actividad o una acción. También se puede utilizar para la descripción de del contenido el lenguaje natural, una especificación formal de expresiones, un metalenguaje, un leguaje de programación (como en la presente investigación), etc. La figura 2.2 muestra la notación de una actividad.

Nombre de la Actividad

Figura 2.2. Representación de una actividad.


- 18 -

Transiciones: Reflejan el cambio de estado, de actividad o de acción. La transición es representada simplemente por una línea con una flecha en su terminación para indicar su dirección. La figura 2.3 muestra la notación para una transición.

Figura 2.3. Representación de una transición.

Inicio y fin: Como todo flujo de control debe empezar y terminar en algún momento. Para indicar dónde empieza y termina se utilizan los símbolos gráficos inicio y fin representados en la figura 2.4. El inicio es un círculo relleno. Y el fin se representa mediante dos círculos uno pequeño dentro del otro y el más pequeño se encuentra relleno.

Figura 2.4. Representación de los símbolos de inicio y fin de una transición.

Bifurcaciones: En [BOO99c] se usan las bifurcaciones para representar caminos

alternativos. Se utiliza como símbolo el rombo. En cada transición de salida se coloca una expresión booleana que será evaluada una vez al llegar a la bifurcación. La figura 2.5 representa la notación de una bifurcación. Es necesario cerrar el flujo abierto de los caminos alternativos, utilizando un símbolo de merge también representado por un rombo.

Figura 2.5. Representación de la bifurcación mediante un símbolo con forma de rombo.

División y unión también conocidas como barras de sincronización: Existen algunos

casos donde además del flujo secuencial y la bifurcación, se requiere realizar tareas concurrentes. En los diagramas de actividad se representa gráficamente el inicio de la concurrencia mediante el símbolo de división, el final de la concurrencia se representa por el símbolo unión. Ambos se representan por una línea gruesa vertical u horizontal como lo muestra la figura 2.6.

Figura 2.6. Ejemplo de división y unión.

El símbolo de división según [BOO99c] puede tener una transición de entrada y dos o más

de salida. La unión puede tener dos o más transiciones de entrada y una transición de salida.


- 19 -

2.6. Lenguajes visuales En [GON04] se hizo una investigación acerca de los lenguajes visuales que conforman las características visuales (forma, tamaño, posición, orientación, color, textura, etc) de un conjunto de elementos que pueden ser diseñados y las relaciones entre ellos.

La programación visual utiliza expresiones visuales cómo dibujos, gráficas, íconos y cualquier sistema que permita especificar un programa en forma de dos dimensiones [ROM03].

Un lenguaje visual consiste de oraciones visuales donde cada expresión representa la colocación espacial de objetos o íconos. Para definir las expresiones en lenguajes visuales es necesario seguir una gramática, en éste caso, una gramática gráfica (visual). La gramática debe delimitar el dominio de aplicación, identificar los componentes o elementos que utilizará y definir el comportamiento de las relaciones que existen.

2.6.1. Clasificación de las gramáticas visuales En el trabajo de [ROM03] se encuentra la siguiente clasificación:

• Gramáticas de cadena generalizada: Especifican clases restrictivas de lenguajes visuales. • Gramáticas de relación de símbolos: Describen un lenguaje visual, donde cada oración

dentro del lenguaje es representada como un conjunto de objetos visuales con sus relaciones.

• Gramáticas posicionales: Ayudan a definir ubicaciones espaciales de objetos y las relaciones entre ellos, las posiciones pueden ser arriba, abajo, izquierda, derecha, etc., Pero deben definirse explícitamente en las producciones.

La gramática que se utilizó para la generación de código a partir de diagramas de actividad es de tipo relacional.

2.6.2. Gramática visual relacional Una gramática relacional pertenece a las gramáticas libres de contexto. Corresponde a una 6-tupla G (N, ∑, S, R, Attr, P) donde:

N: Representa el conjunto finito de símbolos no terminales. ∑: Corresponde al conjunto finito de símbolos terminales diferentes de N. S: Es el símbolo inicial y pertenece al conjunto de los símbolos no terminales. R: Es el conjunto finito de relaciones entre símbolos. Attr: Es el conjunto finito de relaciones entre símbolos. P: Es un conjunto de producciones.


- 20 -

2.7. Generación de código a partir de diagramas de actividad La generación de código que se basa en modelos produce automáticamente el código de una aplicación a partir de modelos gráficos del comportamiento y de la arquitectura del sistema de software.

Según [CAZ04], la generación automática de código puede aumentar significativamente

la productividad del desarrollador. El proceso de generación se basa en una serie de entradas que pueden ser representadas por un archivo XML. En la figura 2.7 se observa el diagrama de actividad del método sumarPares de la clase Suma que recibe un número entero como parámetro el método sirve para sumar en una variable acumulativa (llamada sumaPares) sólo los números pares que recibe. Éste ejemplo es sólo una ilustración de lo que puede realizarse en la generación de código. En el capítulo 3 se describe el procedimiento de generación de código.

Se observa que el diagrama de actividad (figura 2.7a) que los elementos gráficos contienen código fuente en lenguaje C++. En el trabajo de [ZUN01] se utilizaron fragmentos de código en Java para la generación automática de código debido a que estas expresiones pueden ser copiadas directamente hacia el código generado y presentan menos problemas en la interpretación del código.

Figura 2.7. Transformación de diagramas de actividad a código Las estructuras de control están representadas por los elementos gráficos del diagrama de

actividad y la semántica por fragmentos de código en un lenguaje específico como se vio en el capítulo anterior. Las estructuras de control se pueden ubicar con el uso de técnicas para el parseo de gramáticas visuales.

2.8. Métricas de los diagramas UML Para medir la correspondencia de las estructuras en el diagrama de actividad contra las estructuras del código fuente que se generaron a partir del diagrama de actividad se analizaron las métricas de diagramas de actividad y de código fuente que permitieran establecer un punto de comparación. En el trabajo de [MCQ06] se dice que al hacer mediciones del diseño y código se

public class Suma { public int sumarPares (int numero) { if (numero%=!=0) sumaPares=sumaPares+numero; } };

a) Diagrama de actividad del método sumarPares

b) Código en C++ del método sumarPares

Suma::sumaPares(int numero)

(numero%2)!=0

sumaPares= sumaPares+numero;

El símbolo % es utilizado para obtener el residuo de la división entera en lenguaje C++


- 21 -

determina el ciclo de vida del software, la desviación entre los diseños y el código sirve para evaluar las herramientas de ingeniería inversa. Las métricas deben ser elaboradas en los términos del modelo y para ser reusables deberán estar definidas para el nivel de diseño y de implementación del modelo de software.

Las métricas para el nivel de implementación pueden ser métricas de los modelos. Y se deberán considerar los diagramas UML con etiquetas OCL de preferencia, debido a que OCL es el estándar y se utiliza según [REY05] para la definición de relaciones de navegación, profundidad de la navegación, operadores de comparación. OCL es un lenguaje de restricciones y sus sentencias no pueden cambiar el estado de un objeto, es por eso que no se aplica a diagramas de actividad que modelen las estructuras de control (OCL cuenta con la definición de estructuras control). El lenguaje que se desea generar puede ser un buen auxiliar para las etiquetas de los elementos en el caso de los diagramas de actividad.

La tabla 2.1 muestra algunos trabajos donde es aplicado OCL para el texto contenido en

los elementos gráficos de los modelos UML.

Tabla 2.1. OCL aplicado en diagramas de UML

Referencia Aplicación en diagramas

Campo de aplicación Descripción

[TAK06] DA Modelado de procesos de negocio

Es una investigación acerca del uso de modelado de procesos de negocio. Realiza una extensión al lenguaje OCL definido por la OMG para utilizarlo en diagramas de actividad.

[ARL05] DA Etiquetas de transiciones Nodo objeto Nodos estado

Es un libro que describe las posibles aplicaciones de OCL en diagramas de actividad.

[REY05] DCl Restricción del diagrama de clases

Esta investigación describe el uso de OCL en la restricción y especificación del diagrama de clases.

DA: Diagramas de actividad DCl: diagramas de clases

2.8.1. Métricas de Chidamber y Kemere Un análisis de las métricas de Chidamber y Kemere realizado por [MCQ07] dice que consisten en seis tipos de métricas y se refieren a clases individuales del sistema:

1. Peso de los métodos por clase (WMC, Weighted Methods Per Class): se obtiene mediante identificar y contar los métodos de una clase. Al considerar la complejidad ciclomática de Mc Cabe para calcular la complejidad de cada método se le conoce como WMcc.

2. Profundidad del árbol de herencia (DIT, Depth of Inheritance Tree): representa el número de descendientes de una clase.

3. Número de hijos (NIC, Number of Children): Número de métodos que pueden ser invocados mediante un objeto de una clase en particular.

4. Acoplamiento entre clases de objetos (CBO, Coupling between Object Classes): Permite obtener la información acerca de las interacciones entre los métodos de diferentes clases.

5. Respuesta para una clase (RFC, Response For a Class): Representa la profundidad máxima del árbol de herencia.


- 22 -

6. Carencia de cohesión en los métodos (LCOM, Lack of Cohesion in Methods): Los diagramas de secuencias pueden ser utilizados para calcular ésta métrica y representa el uso de variables de instancia mediante los métodos de una clase en particular. Los autores como Baroni, Tang y Chen realizan métricas para diferentes diagramas.

• Baroni hace métricas acerca de los diagramas de clase. • Tang y Chen realizaron métricas para los diagramas de clases, actividades y

colaboración.

El análisis anterior de las métricas para diagramas UML permitió identificar a la métrica WMCcc como la mejor opción de métricas para estructuras de control en diagramas de actividad.

La complejidad ciclomática se puede estudiar como un grafo que contiene nodos, arcos y

flujo de control. A continuación se describen los conceptos anteriores antes de mostrar un ejemplo de la métrica propuesta para diagramas de actividad y código fuente.

2.8.1.1. Estructura del flujo de control El flujo de control permite visualizar identificar el orden en que se ejecutaran las sentencias en la ejecución de un programa. Los diagramas de actividad también tienen flujo de control y se rige por la dirección que siguen las transiciones. Estructura del Flujo de Control: Es la secuencia en que se ejecutan las instrucciones. [MAR07]. Las mediciones de flujo de control son usualmente modeladas a partir de grafos dirigidos, llamados grafos de control de flujo (flowgraphs).

• Nodo: Secuencia de programa. Enumeran las sentencias del programa. • Arco: Flujo de control de una sentencia a otra. Muestran el patrón de control.

2.8.1.2. Grafo de flujo de control

• Grafo: conjunto de nodos y segmentos. • Grafo Dirigido: cada segmento tiene asignada una dirección indicada por una flecha, llamada arco. Es el conjunto de nodos y arcos. Cada arco conecta un par de nodos. • Arco: par ordenado < x, y > donde x e y son los nodos de los extremos. La dirección del arco es de x a y. • Grado-in: número de arcos que llegan a un nodo. • Grado-out: número de arcos que dejan un nodo. Hay dos operaciones básicas que se pueden utilizar para construir un grafo de flujo:

secuencia y anidamiento. Bohm y Jacopini describen en su trabajo [BOH66] (vigente hasta hoy en día) que cualquier algoritmo puede ser implementado usando las construcciones de secuencia, selección y anidamiento.


- 23 -

2.8.2. Métricas de estructuras de control Para seleccionar métricas para código fuente se analizaron las métricas que podían ser aplicadas en estructuras de control y se describen a continuación.

2.8.2.1. Prueba de la ruta base. La prueba de la ruta base es una prueba de caja blanca que fue propuesta por primera vez por Tom Mc Cabe, permite al diseñador de casos de prueba derivar una medida de la complejidad lógica de un procedimiento y usar su medida como una guía para la definición de un conjunto básico de rutas de ejecución.

2.8.2.2. Notación de gráficos de flujo Antes de introducir el método de prueba de rutas base, se debe describir una notación simple para la representación del flujo de control llamada gráfico de flujo. El gráfico de flujo representa la lógica del control de flujo usando la notación de la figura 2.8, ésta notación es utilizada como referencia para la generación de código y el modelado de los diagramas de actividad:

Figura 2.8. Notación de gráfico de flujo [PRE05]

En la figura cada gráfico de flujo tiene un flujo definido y representado por flechas que indican la dirección del flujo. En la presente investigación se utiliza la secuencia, el if, el while, el until, pero no el case debido a que la estructura case se puede modelar utilizando múltiples condicionales anidadas.

Para poder mostrar el uso de los gráficos de flujo, primero se considera el procedimiento mostrado en la figura 2.9a y su representación en gráfico de flujo figura 2.9b.


- 24 -

Figura 2.9. Representación de un diagrama de flujo en un gráfico de flujo [PRE05].

Refiriéndose a la figura 2.9b cada círculo se llama nodo, representa una o más sentencias. Una secuencia de cajas de procedimiento y un diamante de decisión pueden ser mapeados a un sólo nodo. Las flechas en el gráfico de flujo son llamadas ejes o enlaces, representan el control de flujo y son análogas a las flechas de los diagramas de flujo. Un eje debe de terminar en un nodo, aún si el nodo no representa una sentencia. Las áreas acotadas por ejes y nodos son llamadas regiones. Cuando se cuentan regiones, se incluye el área fuera del gráfico como región.

Cuando se encuentran condiciones compuestas en un procedimiento diseñado, la generación de un gráfico de flujo se vuelve más complicada. Una condición compuesta ocurre cuando uno o más operadores boléanos se presentan en una sentencia condicional. La figura 2.10 muestra como se conformaría el gráfico de flujo de una sentencia con una condición compuesta.

Figura 2.10. Gráfico de flujo de una sentencia con condición compuesta [PRE05]

2.8.2.3. Ruta independiente de programa Una ruta independiente es cualquier ruta a través del programa que introduce al menos un nuevo conjunto de sentencias a procesar o una nueva condición. Cuando se describe un gráfico de flujo, una ruta independiente se mueve al menos a lo largo de un eje que no ha sido recorrido antes de

b. Gráfico de flujo a. Procedimiento


- 25 -

que la ruta sea definida. Por ejemplo, un conjunto de rutas independientes para el gráfico de flujo de la figura 2.9b es:

Ruta 1:1-11 Ruta 2:1-2-3-4-5-10-1-11 Ruta 3:1-2-3-6-8-9-10-1-11 Ruta 4:1-2-3-6-7-9-10-1-11

La ruta 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 no es una ruta independiente porque es una

combinación de rutas anteriormente especificadas y no atraviesa ningún nuevo eje.

Las rutas 1, 2, 3 y 4 constituyen un conjunto base para el gráfico de flujo de la figura 2.9b. Si se crea una prueba que recorra las 4 rutas, se garantiza que todas las sentencias del programa van a ser ejecutadas al menos una vez y todas las condiciones van a ser evaluadas en los lados de verdadero y falso.

2.8.3. Medida de complejidad ciclomática de Mc Cabe El cálculo de la complejidad ciclomática permite ayudar a conocer cuantas rutas independientes pueden existir. La complejidad ciclomática es una métrica de software que proporciona una medida cuantitativa de la complejidad lógica de un programa. Cuando se usa en el contexto de la prueba de la ruta base, el valor calculado de la complejidad ciclomática define el número de rutas independientes dentro del conjunto base de un programa y proporciona un límite superior de pruebas que deben realizarse para asegurar que todas las sentencias serán ejecutadas al menos una vez.

La complejidad ciclomática tiene sus fundamentos en la teoría de grafos y se calcula en alguna de las siguientes formas:

1. El número de regiones en un grafico de flujo, corresponde a la complejidad ciclomática. 2. La complejidad ciclomática V(G), para un gráfico de flujo G, se define:

V (G)=E-N+2 Donde E es el número de ejes, y N es el número de nodos. La complejidad ciclomática V (G), para un gráfico de flujo G, se define también como: V (G)=P+1 Donde P es el número de nodos de predicado contenidos en el gráfico de flujo. Los predicados compuestos se cuentan por 2.

Es por eso, v no puede ser usada como una medida general de complejidad. El número

ciclomático es un indicador útil de la dificultad para probar y mantener un programa o módulo. Si v > 10 = problemático.


- 26 -

e = 14 (números de las flechas) e = 10 (números de las flechas) n = 12 (números dentro de las figuras) n = 8 (números dentro de las figuras) V (G) = 14 - 12 + 2 = 4 v (G) = 10 - 8 + 2 = 4

Figura 2.11. Números ciclomáticos de dos diagramas de flujo

La complejidad ciclomática de un programa formado por varios módulos es igual a la

suma de las distintas complejidades.

La fórmula de la sumatoria de complejidad ciclomática obtenida de [PRE05] está representada en (2.1)

La fórmula de la suma de complejidades obtenida de [PRE05] está representada en (2.2)

2.8.4. Cuenta de decisión (DE) La estructura lógica de un programa es el mecanismo que permite realizar las distintas funciones para las que fue construido. La estructura lógica del programa representa los algoritmos empleados en su diseño y procesa los datos. La estructura de un algoritmo se representa perfectamente con las gráficas denominadas diagramas de flujo. Son muchos los métodos de medición del software que se basan en estos diagramas.

El flujo de control en un programa es habitualmente secuencial, aunque puede ser interrumpido en ciertas ocasiones:

• En una decisión, se divide en dos nuevas líneas de flujo que responden a la evaluación de

una condición determinada. • Un salto hacia atrás devuelve el flujo de control a una instrucción que ya ha sido

ejecutada. Normalmente son la base de los bucles.

(2.1)

(2.2)


- 27 -

• Una transferencia de control a una rutina o procedimiento externo, hace que el flujo discurra por un camino externo al programa.

La métrica denominada cuenta de decisión (DE) mide la cantidad de veces que ocurren situaciones como las mencionadas en primer y segundo lugar. Esto es, cuenta el número de instrucciones de decisión y bucles condicionales. A la hora de contar decisiones debe tenerse en cuenta los casos en que estas son compuestas, en esta situaciones DE cuenta predicados más que instrucciones en sí, por lo que las situaciones en las que se usan los operadores AND y OR incrementan en más de uno el valor de DE (algo similar ocurre con instrucciones del tipo CASE).

Una métrica más sofisticada referida a esta misma cuestión es el número de complejidad ciclomática (V (G)). Esta medida está orientada a valorar el número de caminos linealmente independientes de un programa, lo que está relacionado con la facilidad para probar y mantener el código. El número de complejidad ciclomática puede asimilarse al número de líneas que constituirían el "esqueleto" de un diagrama cuyo flujo se ha simplificado al máximo.

2.8.5. Métricas compuestas. Las medidas descritas hasta ahora permiten medir una única magnitud como una característica del software. Sin embargo, ocurre con frecuencia que para describir una determinada cualidad del software es preciso componer (construir un par) de medidas simples llamadas métricas del software.

2.8.6. Métrica propuesta Basada en la métrica de Peso de los métodos por clase (WMC, por las siglas en inglés de Weighted Methods Per Class) de Chidamber y Kemere analizada por [MCQ07]. A la métrica WMCcc que obtiene el cálculo de la complejidad ciclomática por método se propone agregar el cálculo de cuenta de decisión (DE) debido a que DE se enfoca principalmente las estructuras de control. La tabla 2.2 muestra algunas de las métricas aplicadas en diagramas UML. El cálculo de WMCcc se realizará con el código fuente y los diagramas de actividad para poder establecer un punto de comparación en la desviación del modelo contra el código fuente (característica de las métricas de UML [MCQ06]). Los diagramas de actividad pueden ser tratados como redes de Petri (formalización de diagramas de actividad [STO06]) lo que permite visualizarlos como grafos. Con el grafo del diagrama de actividad se puede obtener la complejidad ciclomática de los diagramas de actividad. La presente investigación desarrolló la generación de código para flujo concurrente, donde cada hilo del flujo concurrente es tratado como un subprograma independiente al momento de calcular la métrica.


- 28 -

Tabla 2.2. Métricas aplicadas a diagramas UML

Métrica Diagramas utilizados Complejidad Herencia Encapsulamiento Acoplamiento Cohesión Estructuras

de control

WMC DA, DS, DC √

NOC DCl √ CBO DS √ RFC DCl, DS, DC √ DIT DCl LCOM DS √ WMCcc DA (RP) √ √ DE DA (RP) √ √

WMC: Weighted Methods Per Class DA: Diagrama de Actividad WMCcc: Weighted Methods Per Class and complexity cyclomatic. DS: Diagrama de Secuencias DIT: Depth of Inheritance Tree DC: Diagrama de Colaboración NIC: Number of Children DCl: Diagrama de Clases CBO: Coupling between Object Classes RP: Redes de Petri RFC: Response For a Class LCOM: Lack of Cohesion in Methods


- 29 -

2.8.7. Ejemplo de la métrica propuesta A continuación se van a sacar los valores de la métrica compuesta (DE, CC) del procedimiento de la figura 2.12. El procedimiento average representa el método de una clase.

Figura 2.12. Procedimiento para obtener la complejidad ciclomática [PRE05] Las letras A, B y C de la figura 2.12 muestran los predicados de decisión. V (G)=P+1. V (G)=5+1 P=5 porque se tienen 2 predicados compuestos más 1 simple. DE=3, porque se tienen 3 sentencias de decisión o de ciclo. (Ver los números 1, 2 y 3) en la figura 2.13)

PROCEDURE average; *Este procedimiento calcula el promedio de 100 o menos números que se encuentran entre valores acotados; y también calcula la suma y el total de los números válidos INTERFACE RETURNS average, total.input, total.valid; INTERFACE ACCEPTS value, minimum, maximum; TYPE value[1:100] IS SCALAR ARRAY TYPE average, total.input, total.valid, minimum, maximum, sum IS SCALAR TYPE i IS INTEGER; i=1; total.input = total.valid = 0 sum = 0; DO WHILE value[i]=<>-999 AND total.input<100

increment total.input by 1; IF value[i]>=minimum AND value[i]<=maximum THEN increment total.valid by 1; sum = sum +value[i]; ELSE skip END IF increment I by1;

ENDDO IF total.valid > 0 THEN average = sum/total.valid; ELSE average= -999; ENDIF END average

A

B

C 3

2

1


- 30 -

El diagrama de actividad que representa el programa de la figura anterior es el siguiente:

Promedio::double CalcularPromedio

int i=1;int minimo; int maximo;

value[i]=¡-999 && totali<100

double totali=0;double totalv=0;double suma=0; double promedio=0;

double value[]=new new float[ 100 ];

totalv++;

totalv++;value[i]>=minimo &&value[i]<=maximo

[true]

[false]

suma=suma+value[i]

value[i]>=minimo &&value[i]<=maximo

totalv++;[true]

promedio=-999;

[ false ]

return promedio

i++;

[ true ]

[false]

Figura 2.13. Diagrama de actividad del programa de la figura anterior

Los rombos oscurecidos en color gris indican el inicio y fin de la estructura do-While. Las

estructuras condicionales en verde con números representan las sentencias de decisión. Y los de color amarillo con letras representan los predicados de decisión.

En ambos casos se encuentra que son las mismas estructuras. Recordando que la gramática definida para los diagramas de actividad permite identificar las distintas estructuras de control. La implementación del diagrama de actividad permitirá reconocer los tokens de decisión dentro del diagrama de actividad.

1

2

3

A

B

C


- 31 -

2.9 Conclusiones del capitulo

En éste capítulo se describieron los conceptos necesarios para la transformación de diagramas de actividad a código.

De acuerdo a la clasificación de gramáticas visuales la gramática visual relacional es la

mejor opción para representar las relaciones entre los elementos gráficos del diagrama de actividad.

Las métricas analizadas pertenecen a los diagramas UML y de entre todas ellas se

seleccionó la que podía ser aplicada en diagramas de actividad y estructuras de control debido a que la complejidad ciclomática puede ser medida también en código fuente.

El siguiente capítulo describe como se utilizaron esos conceptos y de que forma

permitieron dar solución al problema de generación de código a partir de diagramas.


- 32 -

Hoja en Blanco


- 33 -

CAPÍTULO 3 En este capítulo se describirán los siguientes aspectos: 3.1 Introducción 3.2 Procedimiento de transformación 3.3 Análisis de los diagramas de actividad y la codificación 3.4 Reglas generadas 3.5 Gramática visual relacional 3.6 Conclusiones del capítulo

Metodología de solución

Capítulo 3. Metodología de solución

- 34 -


3.1. Introducción Los diagramas de actividad de UML tienen elementos gráficos que permiten modelar las estructuras de control como lo son el símbolo inicial, final, condicional y el símbolo actividad los cuales pueden tener un equivalente en código. En la presente investigación se observó la forma para convertir diagramas de actividad a código. La forma se estableció en un procedimiento de transformación de diagramas de actividad a código, después de obtener el procedimiento de transformación se utilizó para generar código fuente en Java.

Con el estudio se observaron las equivalencias que tienen los diagramas de actividad y las estructuras de control y se encontró que existían bloques de instrucciones que pueden contener otros bloques de instrucciones llamados regiones de expansión [UML03].

La figura 3.1a muestra dos regiones de expansión originadas a partir de una estructura selectiva IF_ELSE. Si la condición evaluada es verdadera se realiza un bloque de instrucciones (originando la región de expansión B), si la condición es negativa entonces se realiza otro bloque de instrucciones (región de expansión A). La figura 3.1b muestra el equivalente en código del diagrama de actividad en la figura 3.1a y presenta la equivalencia que tienen las regiones de expansión en código fuente.

a. Diagrama de actividad b. código fuente equivalente del diagrama de actividad

Figura 3.1. Representación de las regiones de expansión condicionales en diagramas de actividad y su representación

en código fuente Las regiones de expansión se identificaron en las estructuras selectivas, repetitivas y en

los diagramas de actividad, las regiones de expansión se describen en éste capítulo.

if (C) {//inicio de la región de expansión B …

… }//fin de la región de expansión B else {//inicio de la región de expansión A

… …

}//fin de la región de expansión A


- 35 -

3.2. Procedimiento de transformación de diagramas de actividad a código El procedimiento de transformación de los diagramas de actividad a código se muestra en la figura 3.2.

Identificar los componentes gráficos del diagrama de actividad

Seleccionar solo los componentes que se desea utilizar en la generación de código a partir de la especificación UML

Definir reglas para esos componentes gráficos

Las reglas representan la forma en como se conectarán los elementos entre sí para que tomen un significado

Establecer una forma para representar los elementos gráficos a código fuente

La relación entre los elementos gráficos permite modelar estructuras de control

Agregar texto a los elementos gráficos para la representación de código

El texto agregado servirá para las etiquetas en las transiciones, en las actividades y en los demás símbolos seleccionados

Figura 3.2. Diagrama de actividad del procedimiento de transformación

El procedimiento de transformación de código consiste en cuatro pasos:

1. Identificación de los componentes gráficos del diagrama de actividad, a partir de la especificación UML para diagramas de actividad se seleccionan los elementos gráficos que se desea utilizar. Para la presente investigación se seleccionaron los símbolos inicio, final, actividad, merge, condicional y las transiciones, estos símbolos son suficientes para modelar las estructuras básicas de control.

2. Definir las reglas para las relaciones entre los elementos gráficos del diagrama de

actividad seleccionados, después de seleccionar los componentes gráficos se debe definir reglas para relacionarlos entre sí, las relaciones definirán la semántica del diagrama de actividad. Lo que se va a modelar con los diagramas son las estructuras básicas de secuenciación, repetición y selección. Para modelar las estructuras de repetición con diagramas de actividad se utilizaron los símbolos condicional, actividad y transición. Para


- 36 -

modelar las estructuras de repetición se utilizaron los símbolos condicional, transición (sin etiquetas y con etiquetas falso y verdadero) y las actividades.

Las reglas utilizadas se definieron como una gramática visual relacional debido a

que éste tipo de gramática permite establecer una relación entre elementos gráficos. La gramática se describe con mayor profundidad en éste capítulo.

3. Agregar texto a los elementos gráficos para la representación de código, la utilización de símbolos gráficos no es suficiente para la generación de código de las estructuras básicas de control, es necesario agregar texto a los diagramas como las etiquetas falso y verdadero de las transiciones en diagramas de actividad (las etiquetas son utilizadas en las estructuras de control de repetición y selección) para definir el flujo de control así como la definición de las condiciones que serán evaluadas en los símbolos condicionales y el texto contenido dentro del símbolo actividad.

En la figura 3.3 se observa el tipo de etiquetas que pueden existir en las

transiciones y son TRUE, FALSE si el inicio de la transición es el símbolo condicional y una transición sin etiquetas si es otro tipo de símbolo. La expresión que se encuentra en el símbolo condicional se representó como una expresión condicional en código fuente (!variable1 es una expresión en código fuente de lenguaje C++ o Java).

Figura 3.3. Texto en diagramas de actividad

4. Establecer una forma para representar los elementos gráficos a código fuente, una vez que

se enriqueció el diagrama de actividad con texto se puede realizar la transformación a código. La transformación de diagramas a código está dirigida por las reglas de producción de la gramática visual relacional, dicha gramática se detalla más adelante en éste capítulo.

Las reglas de producción aplicadas en la generación de código se muestran condensadas en la tabla 3.1. El primer renglón pertenece a la estructura de control condicional IF, cada símbolo condicional abre un flujo de control que deberá ser finalizado con otro símbolo condicional sin texto llamado merge, la columna cuatro indica qué tipo de símbolo es el inicio de la estructura respectiva (IF, IF_ELSE, DO_WHILE, WHILE/FOR) para identificar en el diagrama de actividad, el número de entradas y salidas que pueden tener los símbolos condicional y merge se encuentran en la segunda y tercera columnas. En las estructuras WHILE/FOR existe una transición del símbolo


- 37 -

condicional al merge y en la estructura DO_WHILE una transición del símbolo merge al condicional.

Tabla 3.1. Reglas de producción que permiten transformar los diagramas de actividad a código de las estructuras básicas.

Entradas al

símbolo condicional

Salidas del símbolo

condicional

Entradas al

símbolo merge

Salidas del

símbolo merge

Símbolo inicial de

la estructura del flujo

de control

Transición del símbolo

condicional al merge

Transición delsímbolo mergeal condicional

IF 1 1 1 1 <c> Si Si

IF_ELSE 1 2 2 1 <c> Si Si

DO_WHILE 1 2 2 1 <m> No Si

WHILE/FOR 2 2 1 1 <c> Si

En la figura 3.4a se observa que el símbolo inicio tiene características asociadas al método y la clase que se modela, del símbolo inicio parte una transición sin etiqueta que se dirige al símbolo condicional donde se abren dos flujos (tabla 3.1 renglón 2, columna superior 2) mediante transiciones etiquetadas (uno para la transición etiquetada con TRUE y otra con FALSE), las etiquetas sirven para identificar la región de expansión que se transformará primero en código, siempre se inicia por el flujo de la transición TRUE para la estructura IF_ELSE (según lo mostrado en la tabla 3.1columna cuatro).

La región de expansión de la etiqueta TRUE corresponde al conjunto de sentencias que se ejecutan entre las llaves del IF en el código fuente. La región de expansión de la etiqueta FALSE se transforma después.

a b

Figura 3.4. Transformación de diagramas de actividad a código fuente en Java

import java.io.* public CClaseIFELSE{ public metodoPrueba( ){ if( !variable1){ int variable2; }

else{ int variable3;

} } }


- 38 -

Los diagramas de actividad permiten modelar estructuras de control las cuales tienen una representación en código. Se realizó un análisis de cómo representar la estructura de control modelada en el diagrama a código y se describe en el punto 3.3 de éste capítulo. Ahí se define la región de expansión que pertenece a las estructuras repetitivas y la región de expansión de las estructuras condicionales y sus características.

El punto 3.3.4 contiene una tabla de restricciones en las conexiones de los elementos

visuales del diagrama de actividad. Y el punto 3.3.1.1 muestra cómo afectan éstas restricciones a la codificación del diagrama de actividad.

La gramática visual relacional es explicada en 3.5, la gramática representa una manera de

formalizar los diagramas de actividad. La formalización comprende sólo el modelado de las estructuras de secuenciación, repetición y selección con diagramas de actividad.

3.3. Análisis de los diagramas de actividad y la codificación Los diagramas de actividad permiten el modelado de estructuras de control de secuenciación, repetición y selección. La presente investigación se enfoca en la codificación de las estructuras básicas de los métodos de las clases.

Las estructuras de control secuenciales se representan por bloques de estructuras de control. Las estructuras de control selectivas: representan un conjunto de instrucciones que se

realizaran si una condición es verdadera o falsa. En el trabajo de [STO04c] se analizaron los nodos de actividad estructurada del estándar, definiendo una semántica basada en redes de Petri. Se utilizan los conceptos de nodos condicionales, nodos iterativos, regiones de expansión, regiones de expansión iterativas, regiones de expansión concurrentes definidos en el estándar de la OMG [UML03]. La semántica que se definió es usada en la presente investigación y se describe su aplicación en 3.3.1 y 3.3.2.

3.3.1. Estructuras de selección Nodos condicionales: “es un nodo de actividad estructurada que representa una selección exclusiva entre un número de alternativas.” (Traducción libre del autor acerca de [UML03]).

La figura 3.5 tomada de [STO04c] permite visualizar el modelado de nodos condicionales y se observa que cada apertura del símbolo condicional, estará ligada a un número de acciones y, que el flujo abierto por un símbolo condicional deberá ser cerrado con un símbolo (en el presente trabajo, conocido como merge).


- 39 -

Figura 3.5. Sintaxis sugerida por [STO04c] para los nodos condicionales

En la estructura condicional múltiple la palabra break puede ser opcional, debido a que una estructura de tipo condicional múltiple puede ser inclusiva (si debe evaluar cada condición) o exclusiva (si la evaluación se realiza sólo en una ocurrencia de la condición, para tal caso, cuando encuentre la condición verdadera, deja de comparar entre todas las opciones). La palabra default al final de la sentencia switch se usa para manejar los valores que no se han manejado explícitamente por una de las sentencias case.

Los componentes del diagrama de actividad para el modelado de las estructuras de

selección están definidos en la figura 3.6. La condición que es evaluada en el switch debe de ser de tipo entero o char. Nunca float o double. La representación de ésta estructura está representada en la figura 3.6.

Figura 3.6. Representación del modelado de las estructuras de selección para diagramas de actividad.

Lo importante de identificar en las regiones de expansión son las estructuras de control que pueden contener y la forma en que se pueden interactuar para conducir al fin de la región de expansión.


- 40 -

3.3.1.1. Características de la región de expansión condicional

1. Puede estar compuesta de una o más estructuras, en la figura 3.7 se observa que la región de expansión condicional está compuesta por una actividad.

2. Las estructuras pueden ser secuenciales, contienen bloques de estructuras de control que

no son interrumpidos. Como lo muestra la figura 3.7.

Figura 3.7. Región de expansión condicional con flujo secuencial

3. Las estructuras contenidas dentro de la región de expansión pueden ser estructuras

condicionales. Un ejemplo se observa en la figura 3.8.

Figura 3.8. Región de expansión condicional con estructuras condicionales

4. Las estructuras dentro de la región de expansión pueden ser iterativas. La figura 3.9

muestra una región de expansión iterativa y el código correspondiente de esa región.

/* Codigo en java */ public class prueba { boolean condicion; public int calcular(){ int a = 0; if (condicion) {//región exp. a = System.in.read(); System.out.print(a); }//fin región exp. return 0; } }

leer A

imprimir A

M

C

C

leer A

M

M

/* Codigo en Java.*/ public class prueba { boolean condicion, condicion2; public int calcular(){ int a = 0; if (condicion) {//región exp1. if (condicion2) {//región exp2. a = System.in.read(); }//fin región exp2. }//fin región exp1. return 0; }


- 41 -

Figura 3.9. Región de expansión condicional con estructuras iterativas

5. La figura 3.10 muestra cómo las estructuras de control dentro de la región de expansión podrían conducir al final de la región de expansión y del método sin necesidad de que se ejecute cada instrucción contenida dentro de la región de expansión condicional.

Figura 3.10. Región de expansión condicional que termina debido a una instrucción dentro de ella.

6. Los hilos o threads aunque no son estructuras de control básicas que permiten modelar el

“procesamiento en paralelo”, son estructuras que pertenece a la región de expansión condicional. La figura 3.11 muestra ésta región de expansión.

Figura 3.11. Región de expansión condicional con procesamiento en paralelo (threads)

/*Código en Java*/ public class prueba { boolean condicion; public int calcular(){ int a = 0,i=0; if (condicion){//región exp1. while (i<10) {//región exp iterativa. a = System.in.read(); i++; }//fin región exp iterativa. }//fin región exp1. return 0; } }

C

M

[ FALSE ]

i++

[ TRUE ]

C

C

M

[ FALSE ]

i++

[ TRUE ]

C

break;

/* Código en Java*/ public class prueba { boolean condicion; public int calcular(){ int a = 0,i=0; if (condicion){//región exp1. while (i<10) {//región exp iterativa. a = System.in.read(); i++; break; }//fin región exp iterativa. }//fin región exp1. return 0; } }

public class EjemploHilo { public int pruebaHilos() boolean condicion=true; if (condicion) { PruebaHilo t1, t2; // Crear los threads t1 = new PruebaHilo("Hilo1",(int)(Math.random()*200)); t2 = new PruebaHilo("Hilo2",(int)(Math.random()*200)); t1.start();// Arrancar los threads t2.start(); } return 0; } }

leer a leer b


- 42 -

7. Cada condición evaluada puede contener una región de expansión como lo muestra la figura 3.12.

Figura 3.12. Región de expansión condicional con una región de expansión condicional

3.3.2. Estructuras de repetición Nodos repetitivos: El estándar no tiene una sintaxis concreta para los ciclos y pueden existir diversas interpretaciones para su modelado. Las estructuras repetitivas más comunes de los lenguajes de programación son: do-while, while y el for. El trabajo de [STO04c] propone una región de expansión para los ciclos.

El trabajo de [STO04c] describe las facilidades que proporciona el estándar para implementar ciclos de tipo while-do y repeat-until, con una región de expansión como muestra la figura 3.13 con características: setup, test y body.

En la figura 3.13 se observa la sintaxis sugerida en [STO04c] para los nodos repetitivos.

En setup, se configura la variable de control del ciclo, test evalua la variable, y body representa la región de expansión. La figura 3.13a muestra la sintaxis sugerida para los ciclos y (3.13b, 3.13c, y 3.13d) son expansiones, 3.13c representa la estructura do-while y 3.13d representa la estructura while. Las sentencias condicionales contenidas en las estructuras while y do-while, obedecen a la sintaxis de sentencias_condicionales definidas en ANSI C++.

Figura 3.13. Sintaxis sugerida por [STO04c] para los nodos de repetición.

/* Codigo en Java.*/ public class prueba { boolean condicion, condicion2; public int calcular(){ int a = 0; if (condicion) {//región exp1. if (condicion2) {//región exp2. a = System.in.read(); }//fin región exp2. }//fin región exp1. return 0; } }

C

C

leer A

M

M


- 43 -

Para la generación de código se consideró el ciclo for y se modeló debido a que pertenece a las estructuras de control en lenguaje de programación. La figura 3.14, muestra el modelado que se realiza para la generación de código con diagramas de actividad. Cuenta con región de expansión, condición y unión de flujo.

Figura 3.14. Estructura del diagrama de actividad para el modelado para las estructuras de control repetitivas.

La estructura del for es idéntica al ciclo while. Su diferencia radica en la condición evaluada. En [DEI03] los componentes del encabezado for para el símbolo condicional son los siguientes:

En el caso de los componentes del encabezado de las estructuras de repetición for, puede

omitirse alguno de las condiciones en la expresión, pero el valor será tomado como verdadero [BAT05]. Las regiones de expansión de la figura 3.14 representan las actividades que se realizaran dentro del ciclo y haciendo una analogía con el trabajo de [STO04c] corresponden al body de la estructura de repetición.

La región de expansión para estructuras de repetición no debe contener concurrencia, debido a que el iniciar flujos concurrentes dentro de un ciclo iterativo podría causar errores de sobrecarga del procesador o errores de ejecución, por eso no es recomendable su uso y no se tomarán en cuenta para el mapeo a código las estructuras concurrentes dentro de la región de expansión repetitiva. La región de expansión repetitiva puede contener hilos dentro de la región de expansión repetitiva pero los hilos localizados dentro de estructuras repetitivas podrán sobrecargar el procesador y producir un fallo inesperado.

3.3.3. Estructuras de ejecución concurrente Región de expansión concurrente: “Es una ejecución que puede suceder en paralelo, o traslapando tiempos” (Traducción libre del autor acerca de [UML03]).

Valor inicial de la variable de control

Condición de continuidad del ciclo

Incremento de la variable de control

, ,for


- 44 -

Una estructura de concurrencia determina el comportamiento del flujo de trabajo. Varias actividades pueden realizarse paralelamente. La región de expansión concurrente tiene características similares a las de la región de expansión condicional. Cada hilo contiene su propia región de expansión. Ver figura 3.15.

Figura 3.15. Regiones de expansión concurrentes.

El número de hilos que inician es el número de hilos que deberán ser finalizados. La

figura 3.15 muestra que cada hilo posee su región de expansión.

3.3.4. Restricciones de las regiones de expansión Los hilos representan subprogramas que se están ejecutando. Un ejemplo es un servidor Web que crea un hilo para responder cada petición que le realizan los clientes y que al terminar de atender la petición del cliente el hilo es cerrado. La región de expansión concurrente no debe tener instrucciones que finalicen la ejecución del método modelado porque provocaría una inconsistencia en los demás hilos abiertos. La figura 3.16 muestra como un hilo finaliza la ejecución del método, dejando inconsistentes los demás hilos abiertos. Cada hilo debe ser finalizado.

Figura 3.16. Finalización del método debido a una instrucción en la región de expansión concurrente N.

No es recomendable que en la región de expansión existan hilos que a su vez llamen a

otros hilos y así sucesivamente, esto es debido a que al utilizar un hilo, es reservado un espacio de memoria y procesador así los recursos disponibles van disminuyendo.

La gestión de los hilos en windows y el linux se hace de forma diferente. Para la implementación de programación concurrente en lenguajes de programación, se utilizan librerías.


- 45 -

Java acepta programación concurrente y se encarga de administrar los hilos. Pero C++ utiliza librerías especializadas como POSIX.

C++ Builder posee un thread propio: TThread. Visual C++ utiliza: CWinThread.

C y C++ realizan llamadas no portables a las primitivas de subprocesamiento múltiple del

sistema operativo.

Java tiene la capacidad de subprocesamiento múltiple1 mientras que lenguajes como C y C++ no tienen directamente debido a que utilizan bibliotecas de código específicas para cada plataforma. Se debe tomar en cuenta que cuando varios subprocesos comparten un objeto pueden ocurrir resultados indeterminados.

1 Java incluye primitivas de subprocesamiento múltiple como parte del mismo lenguaje como parte de las clases del paquete java.lang para manipular subprocesos transparentemente entre plataformas [DEI04]


- 46 -

El siguiente código en Java corresponde a la implementación de un programa que crea dos hilos t1 y t2 que permiten imprimir la variable a. La figura 3.17 muestra el código en Java que representa un ejemplo con hilos.

Figura 3.17. Código en Java que crea y utiliza hilos.

public class EjemploHilo { public int pruebaHilos() { boolean condicion=true; if (condicion) { PruebaHilo t1, t2; // Crear los threads t1 = new PruebaHilo("Thread 1", (int)(Math.random() * 20)); t2 = new PruebaHilo("Thread 2", (int)(Math.random() * 20)); // Arrancar los threads t1.start(); t2.start(); } return 0; } } class PruebaHilo extends Thread { private String nombre; private int retardo,a; // Constructor para almacenar el nombre de cada hilo y el retardo public PruebaHilo(String s, int d) { nombre = s; retardo = d; } // El metodo run() es similar al main(), pero para // threads. Cuando run() termina el thread muere public void run() { // Retasar la ejecución el tiempo especificado try { sleep(retardo); } catch (InterruptedException e) { ; } System.out.print(a); } }


- 47 -

Existen propiedades que deben ser capturadas en el diagrama de actividad para el control de los hilos y pueden observarse en la tabla 3.2.

Tabla 3.2. Mapeo de procesamiento concurrente a diagramas de actividad

Código Java Valor Descripción del mapeo en diagramas de actividad

class NombreClaseHilo extends Thread NombreClaseHilo

Configurado en el símbolo

t1 = new PruebaHilo("Nombre Hilo", (int)(Math.random() * 20));

"Nombre Hilo" Configurado en el símbolo . Cado hilo debe tener un nombre.

t1 = new PruebaHilo("Nombre Hilo", (int)(Math.random() * 20));

Retardo: (int)(Math.random() *

20)

Configurado en el símbolo . Cado hilo debe tener un retardo

El diagrama de actividad que corresponde al código de la figura 3.17 se muestra en la figura 3.18.

M

C

escribir a escribir a

publ ic int EjemploHi lo:: pruebaHi los()

return 0

PruebaHilo

"Thread 1"[ 20 ]"Thread 2"[ 20 ]

Figura 3.18. Diagrama de actividad que corresponde al código de la figura 3.15

La región de expansión de cada hilo debe ser anexada al método run ( ) de la clase NombreClaseHilo.


- 48 -

La tabla 3.3 representa las conexiones de los elementos visuales. Existen restricciones para las conexiones de los elementos visuales.

Tabla 3.3. Conexiones de los elementos visuales de los diagramas de actividad.

Entrada

Salida

Puede existir un método vacío.

El símbolo actividad acepta como entrada el

flujo del símbolo inicio.

El símbolo condicional acepta como

entrada el flujo de inicio.

Después del inicio puede

existir un ciclo

La concurrencia permite como entrada el flujo del símbolo

inicio.

No puede existir el símbolo de fin de concurrencia el

símbolo de inicio.

Existe un diagrama de

actividad con una sola actividad.

La salida de una actividad puede ser la entrada de

otra.

Un símbolo actividad puede

tener como consecutivo e

símbolo condicional.

Después del símbolo actividad

puede iniciar un ciclo

Después de una actividad puede iniciarse el flujo

concurrente.

Existe el símbolo

actividad dentro de la concurrencia mientras exista el símbolo de

inicio de la concurrencia.

Un símbolo condicional

puede conducir al fin del método.

Siempre y cuando no se

encuentre dentro de una

concurrencia .

Un símbolo condicional puede tener

como consecutivo una

actividad.

Pueden existir múltiples

condicionales.

El símbolo C conectado a M significa

un ciclo

Después del símbolo condicional puede

iniciar la concurrencia.

Existe el símbolo condicional dentro de

la concurrencia mientras exista el

símbolo de inicio de la concurrencia.

El símbolo M sirve como

llegada de flujos. Y después de el

puede ir el fin del método.

Después del símbolo M

puede existir actividades. El

símbolo M indica el inicio

de un ciclo

M es predecesor de C cuando ese trata

de un ciclo while. O

cuando se trata de una

condición.

Puede tener anidamiento de hasta de 3

ciclos.

No se permite concurrencia dentro

de un ciclo

No se permite la concurrencia dentro

de un ciclo

No terminar el método dentro de la concurrencia porque causaría inconsistencia.

La concurrencia puede tener una actividad como consecuente.

Dentro de la

concurrencia es permitido el

símbolo condicional,

siempre y cuando no lleve

al fin del método.

En la concurrencia

, pueden existir ciclos.

No se permite la anidación de concurrencia.

Símbolo obligado para el cierre de la concurrencia

El final de la

concurrencia puede ser el final

del método.

El símbolo actividad puede ser consecutivo

de la concurrencia.

Después de terminar la

concurrencia es permitido el

símbolo condicional

como predecesor.

Después de terminar

concurrencia puede existir

un ciclo

Hasta que se termine el flujo de

concurrencia anterior no se realiza uno

nuevo.

No puede existir la concurrencia vacía.

Conexiones condicionadas de los elementos visuales.


- 49 -

3.4. Reglas generadas El símbolo inicio indica el inicio del diagrama de actividad que se está modelando y puede estar vinculado al método de una clase, en el caso de que se esté modelando código orientado a objetos.

3.4.1. Reglas que pertenecen al símbolo inicio Para lograr la consistencia del diagrama de actividad el símbolo inicio deberá estar vinculado al método de la clase que se está modelando (en el caso de que se modele orientado a objetos). En la figura 3.19, se observa la clase Suma y el método sumar (), en el diagrama de actividad el símbolo inicio deberá estar relacionado al método sumar ().

a. Diagrama de la clase suma b. Símbolo inicial Figura 3.19. Relación del símbolo inicio del diagrama de actividad con el diagrama de clases

3.4.1.1. Símbolo inicio y símbolo fin Puede existir un método vacío, como lo muestra la figura 3.20.

Figura 3.20. Representación del método vacío.

3.4.1.2. Símbolo inicio y símbolo actividad En la figura 3.21 se representa el símbolo inicio acepta como símbolo sucesor al símbolo actividad.

Actividad

Figura 3.21. Representación del flujo secuencial de actividades.

3.4.1.3. Símbolo inicio y símbolo condición Después del inicio puede existir una condición. La figura 3.22 muestra como el símbolo condición puede ser precedido del símbolo inicial.

Suma::sumar(double numero1, numero2)

Sumanumero1 : Double = 0numero2 : Double = 0

sumar()


- 50 -

sumaPares=sumaPares+numero

[ ( (numero%2)!=0 ) ]

El % calcula el resto de la división entera en lenguaje c++

Figura 3.22. Representación de una condición después del símbolo inicio.

3.4.1.4. Símbolo inicio y símbolo merge Después del símbolo inicio puede comenzar un ciclo como se ve en la figura 3.23.

suma=suma+i;i++;

suma=0;i=1;

Sumar los numeros del 1 al 20

i<21

Figura 3.23. Representación de un ciclo de tipo while después del símbolo inicio.

3.4.1.5. Símbolo inicio y símbolo concurrencia inicio La concurrencia inicio puede estar después del símbolo inicio. El símbolo concurrencia inicio puede preceder al símbolo inicio como lo muestra la figura 3.24.

Actividad1

Actividad2

Figura 3.24. Representación de la concurrencia después del símbolo inicio.

3.4.1.6. Símbolo inicio y concurrencia fin El símbolo concurrencia fin no puede colocarse después del símbolo inicio, debido a que el símbolo concurrencia fin necesita el símbolo concurrencia fin para la generación de código. Como se observa en la figura 3.25,

C

M

M

C


- 51 -

NewState4

Figura 3.25. La conexión entre los símbolos inicio y concurrencia fin no es posible.

3.4.2. Reglas que pertenecen al símbolo final. En el símbolo fin se definió asociar el retorno de valores de parte de los métodos.

3.4.2.1. Inconsistencias con el símbolo fin El símbolo fin representa la terminación de la ejecución del método. Ningún símbolo precede al símbolo fin. Su atributo es sólo de entrada. La aparición de éste símbolo no debe generar inconsistencias o terminaciones abruptas de código. La figura 3.26 muestra una terminación del método que genera inconsistencia porque la condición conduce al símbolo fin dejando los flujos concurrentes inconsistentes.

Actividad1

Actividad2

true

Figura 3.26. Ejemplo de terminación inconsistente del modelo.

3.4.3. Reglas que pertenecen al símbolo actividad. El trabajo de [WOH04] analiza patrones de flujo de control y de datos de la versión 2.0 de UML, dividiendo las acciones (son las que modifican el estado del sistema) como:

• Acciones de invocación • Acciones de lectura y escritura • Acciones computables.

Las investigaciones de [ZUN01] y [LOP07] indican que para generar código de un lenguaje especifico, lo más recomendable es que se agreguen fragmentos de código que se desea generar a los modelos de los DA. No existe un pseudocódigo estándar.

Y tomando en cuenta el trabajo de [WOH04] el símbolo actividad puede tener asignado

código de lectura y escritura.


- 52 -

Para el símbolo actividad pueden existir acciones de invocación, acciones de lectura y escritura y acciones computables. Acciones de invocación: Consisten en la llamada de las operaciones, envío de señales y aceptación de eventos. Acciones de lectura y escritura: Permiten el acceso y modificación de objetos y sus valores. Para lograr la lectura de variables y constantes se utiliza la palabra leer y escribir dentro de las actividades. Estas palabras son utilizadas con el fin de no comprometer la impresión o escritura a un tipo de datos en particular.

En la codificación para Java se utiliza la instrucción:

System.out.println (" "); En la codificación para C++ pueden utilizarse las instrucciones cin y cout.

cout << ” ” cin>> “ “

La figura 3.28 muestra la representación de acciones de lectura y escritura con diagramas

de actividad.

Leer (NumeroA);Leer (NumeroB);

Escribir("El primer numero es:",A);

Figura 3.27. Representación de la lectura y escritura utilizando diagramas de actividad y pseudocódigo.

Acciones computables: Las acciones computables transforman valores de entrada y salida. Las actividades pueden contener código en un lenguaje en particular, el cual es copiado directamente dentro del código que se está generando. Por lo tanto es posible escribir código de varios lenguajes dentro del diagramador. Pero para este caso de estudio solamente se genera código para Java. Existen expresiones para el lenguaje. Las cuales son compatibles en los lenguajes Java y C++. Dentro de las acciones computables se encuentran las acciones de asignación. Expresiones de asignación: El operador de asignación (=) hace que el valor situado a la derecha del operador se adjudique variable situada a su izquierda. La asignación suele ocurrir como parte de una expresión de asignación y las conversiones se producen implícitamente.


- 53 -

3.5. Gramática visual relacional Una gramática relacional pertenece a las gramáticas libres de contexto. Corresponde a una 6-tupla G (N, ∑, S, R, Attr, P) donde:

N: Representa el conjunto finito de símbolos no terminales. ∑: Corresponde al conjunto finito de símbolos terminales diferentes de N. S: Es el símbolo inicial y pertenece al conjunto de los símbolos no terminales. R: Es el conjunto finito de relaciones entre símbolos. Attr: Es el conjunto finito de atributos de los símbolos. P: Es un conjunto de producciones.

3.5.1. Gramática visual relacional de los diagramas de actividad

G (N, ∑, S, R, Attr, P) N= {Diagrama, Actividades, ActividadesConcurrentes, Estructuras, Concurrencia, Secuenciales, Condicional, While, DoWhile, For, If, IfElse, Final, ActividadesConFin} S= {Diagrama}

T={ , , , , , , } R= {Transición, TransiciónCTRUE, TransiciónCFALSE } Attr = {Entrada, Salida}

Los elementos visuales definidos para T, para los fines de ésta investigación tienen los siguientes nombres:

inicio Fin actividad condicional merge concurrencia inicio

concurrencia fin

transición

3.5.1.1. Atributos (Attr) Los atributos de los elementos visuales del diagrama de actividad son los siguientes:

Atributos de Entrada: Atributos de Salida:

Atributos de Entrada/Salida: , , , , , N


- 54 -

3.5.2. Reglas de producción

3.5.2.1. Desde el estado inicial

Producción Descripción

D1

Diagrama Actividades Final Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2; Transición Salida 2, Entrada 3 Transición Salida 3, Entrada 0

D2

Diagrama Transición Salida 0, Entrada 1 Transición Salida 1, Entrada 2 Transición Salida 2, Entrada 0

3.5.2.2. Desde el estado final


F1

Final Transición Salida 0, Entrada 1 Transición Salida 1, Entrada 0

3.5.2.3. Desde el estado Actividades


A1 Actividades Actividades

Concurrentes Transición Salida 0, Entrada 1

Transición Salida 1, Entrada 0

A2

Actividades Actividades Concurrentes

Actividades Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

A3 Actividades Estructuras Transición Salida 0, Entrada 1


A4

Actividades Estructuras Actividades Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

3.5.2.4. ActividadesConFin


AF1

Actividades ConFin

Actividades ConFin

Estructuras Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

AF1 Actividades

ConFin Estructuras Transición Salida 0, Entrada 1


AF1

Actividades ConFin

Estructuras Fin Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

3.5.2.5. Desde el estado ActividadesConcurrentes


AC1 Actividades

Concurrentes Estructuras Transición Salida 0, Entrada 1



- 55 -

AC2

Actividades Concurrentes

ActividadesConcurrentes Estructuras Transición Salida 0, Entrada 1 Transición Salida 0, Entrada 2 Transición Salida 1, Entrada 0 Transición Salida 2, Entrada 0

3.5.2.6. Desde el estado Estructuras


E1 Estructuras Secuenciales Transición Salida 0, Entrada 1


E2

Estructuras Estructuras Secuenciales Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

E3 Estructuras Ciclo Transición Salida 0, Entrada 1


E4

Estructuras Estructuras Ciclo Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

E5 Estructuras Condicional Transición Salida 0, Entrada 1


E6

Estructuras Estructuras Condicional Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

3.5.2.7. Desde el estado Secuencial


S1

Secuenciales Secuenciales Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2 Transición Salida 2, Entrada 0

S2 Secuenciales Transición Salida 0, Entrada 1


3.5.2.8. Desde el estado Concurrencia


P1

Concurrencia Actividades Concurrentes

Transición Salida 0, Entrada 1 Transición, Salida 1, Entrada 2; Transición Salida 2, Entrada 3 Transición Salida 3, Entrada 0

3.5.2.9. Desde el estado Ciclo


C1 Ciclo While Transición Salida 0, Entrada 1


C2 Ciclo DoWhile Transición Salida 0, Entrada 1


C3 Ciclo For Transición Salida 0, Entrada 1



- 56 -

3.5.2.10. Desde el ciclo While


W1

While

Actividades

ConFin

Transición Salida 0 Entrada1 TransiciónCTRUE Salida 1 Entrada 2

Transición Salida 2 Entrada 3 Transición Salida 3, Entrada 1

TransiciónCFALSE Salida 1, Entrada 0

3.5.2.11. Desde el ciclo DoWhile


D1

DoWhile

Actividades

ConFin

Transición Salida 0 Entrada1 Transición Salida 1 Entrada 2 Transición Salida 2 Entrada 3

TransiciónCTRUE Salida 3, Entrada 1TransiciónCFALSE Salida 3, Entrada

0

3.5.2.12. Desde el ciclo For


F1

While

Actividades ConFin

Transición Salida 0 Entrada1 TransiciónCTRUE Salida 1

Entrada 2 Transición Salida 2 Entrada 3 Transición Salida 3, Entrada 1 TransiciónCFALSE Salida 1,

Entrada 0

Nota: Aunque While y For tienen la misma forma, La distinción radica en el texto asociado al símbolo condicional. El símbolo de condicional, debe tener asociado texto. El símbolo merge solo sirve para recibir flujos de trabajo, no contiene texto asociado ni sentencias condicionales.

3.5.2.13. Desde el estado Condicional


B1

Condicional If

Transición Salida 0, Entrada 1 Transición Salida 1, Entrada 0

B2

Condicional IfElse

Transición Salida 0, Entrada 1 Transición Salida 1, Entrada 0


- 57 -

3.5.2.14. Desde el estado IfElse


Ie1

IfElse

Actividades ConFin

Actividades ConFin

Transición Salida 0 Entrada1 TransiciónCTRUE Salida 1, Entrada 2 TransiciónCFalse Salida 1, Entrada 3

Transición Salida 2, Entrada 4 Transición Salida 3, Entrada 4 Transición Salida 4, Entrada 0

3.5.2.15. Desde el estado If


I1

If

Actividades ConFin

Transición Salida 0, Entrada 1 TransiciónCTRUE Salida 1, Entrada 2

Transición Salida 2, Entrada 3 TransiciónCFALSE Salida 1, Entrada 3

3.6. Conclusiones del capítulo En éste capítulo se observó que los diagramas de actividad están representados por símbolos gráficos relacionados entre sí. Una forma de relacionarlos fue siguiendo reglas representadas por la gramática visual relacional. Una vez construido el diagrama fue necesario agregar información adicional para generar código. Instrucciones que nos permitieran interpretar la semántica del diagrama de actividad en cuanto a estructuras de control. Después de analizar las opciones (OCL o lenguaje de programación) se llegó a la conclusión de que el lenguaje de programación era el mejor debido a que OCL es un lenguaje de restricciones. Con el diagrama construido ya se pudo lograr una interpretación a código pero deberían de analizarse las estructuras anidadas. Las estructuras anidadas modeladas en el diagrama de actividad (regiones de expansión) tienen características propias de cada estructura y afectan la generación de código. Con toda la información anterior ya se pudo realizar un mapeo a código del diagrama de actividad, pero realizarlo manualmente es muy tardado, así que se implementó la solución en una herramienta llamada ADCODE que lo realizara de manera automática. El siguiente capítulo describe el desarrollo de la herramienta para la validación del procedimiento de generación de código desarrollado en éste capítulo.


- 58 -

Hoja en Blanco


- 59 -

CAPÍTULO 4 En este capítulo se describirán los siguientes aspectos: 4.1 Introducción 4.2 Escenarios de casos de uso 4.3 Diagramas de secuencias 4.4 Diagramas de clases 4.5 Ejecución de la herramienta 4.6 Conclusiones del capítulo

Validación de procedimiento de transformación

Capítulo 4. Validación del procedimiento de transformación

- 60 -


4.1. Introducción El desarrollo de la herramienta surge con la necesidad de automatizar el procedimiento de generación de código definido en el capítulo anterior. Un diseñador necesita modelar diagramas de actividad y obtener código de esos diagramas rápidamente (ver figura 4.1) no puede perder tiempo valioso al realizar el procedimiento de transformación en forma manual.

Figura 4.1. Necesidad del diseñador

Los diagramas de actividad son una representación gráfica del diseño detallado de los métodos de las clases. En el presente capítulo se observa como automatizar los cuatro pasos del procedimiento de transformación de código definido en el capítulo anterior y se describen a continuación:

1. Identificación de los componentes gráficos del diagrama de actividad: Los símbolos que

se utilizaron para el modelado de las estructuras de control son los símbolos inicio, fin, actividad, transición, condicional y merge. Se requería de un diagrama de actividad como entrada para la transformación de código. Y se elaboró una herramienta que permitiera realizar la construcción de diagramas de actividad a la cual se denominó como ADCODE.

2. Definir las reglas para las relaciones entre los elementos gráficos del diagrama de actividad seleccionados: Con la herramienta ADCODE se logró dibujar diagramas de actividad, pero era necesario dar una semántica a la unión de varios elementos gráficos del diagrama y para lograrlo se elaboró una gramática visual relacional que permitía verificar la conexión de los elementos gráficos cada vez que un símbolo era dibujado en el diagrama de actividad con la herramienta ADCODE; hasta éste punto se logró obtener la estructura del flujo de control de las estructuras condicionales, secuenciales y repetitivas. Pero aún faltaba especificar más elementos requeridos en el código fuente.

3. Agregar texto a los elementos gráficos para la representación de código: Los dibujos solo significaban la estructura del flujo de control en el diagrama de actividad. Pero faltaba agregar elementos para lograr la codificación, los elementos representados por el

Generar código a partir de diagramas de actividades

Modelar Diagramas de Actividades


- 61 -

contenido del símbolo actividad, condicional, y las etiquetas en transiciones deberían ser definidas para realizar la transformación a código. El texto que se utilizó para enriquecer los diagramas de actividad fue código fuente en Java (según lo propuesto por [TRO03] quien afirma que lo más recomendable es utilizar código fuente del lenguaje que se desea generar)

4. Establecer una forma para representar los elementos gráficos a código fuente: Los atributos y las producciones de la gramática visual relacional permitieron modelar la estructura del flujo de control y la semántica de los diagramas de actividad. Siguiendo las reglas de producción se pudo realizar la transformación de los diagramas de actividad a código.

Para ser más específico el procedimiento de transformación en cuanto a la aplicación de él en una herramienta se realizaron los siguientes pasos:

1. Generar el diagrama de actividad. 1.1 Validar cada transición que se agregó al diagrama de actividad: La validación consiste en revisar el símbolo inicio y final de cada transición y verificar que sea posible realizarla de acuerdo a las reglas definidas en las producciones de la gramática visual relacional.

2. Generar código. Con el diagrama de actividad ya construido, se procedió a generar el código y se realizaron los siguientes pasos:

2.1 Validar que no existan símbolos del diagrama de actividad aislados. 2.2 Obtener la tabla de transiciones del diagrama de actividad. La tabla de transiciones y su contenido se describen más adelante en éste capítulo. 2.3 Eliminar transiciones vacías como las que pertenecen a las estructuras while o for. Las transiciones vacías no generan código, pero son necesarias para modelar las estructuras de control. 2.4 Procesar tabla de transiciones

2.4.1 Ubicar en la tabla de transiciones la transición cuyo origen es el símbolo inicial que contiene la definición de la clase, el método y los parámetros del método de la clase que se modela. 2.4.2 Procesar el origen de la transición para generar código, de acuerdo al símbolo es el tipo de código que genera. 2.4.3 De la transición actual que se seleccionó en la tabla de transiciones, se identifica el destino de la transición y se convierte en el origen. 2.4.4 Se elimina la transición actual de la tabla de transiciones. 2.4.5 Se realiza una búsqueda en la tabla de transiciones para ubicar dónde se encuentra el símbolo origen (antes destino). Y se procesa la transición para la generación de código. 2.4.6 Repetir el paso 2.4.2 hasta que no haya elementos en la tabla de transiciones.

3. Validar el código generado mediante las métricas. Las métricas permiten calcular la complejidad ciclomática del diagrama de actividad y del código fuente en Java.

La implementación del procedimiento de transformación para diagramas de actividad se

representa en la figura 4.2. En la figura se observa que primero es necesario tener un diagrama de actividad que modele un método de alguna clase debido a que la generación de código no se puede realizar sin un diagrama de actividad que transformar. Para crear el diagrama de actividad


- 62 -

se desarrolló una herramienta llamada ADCODE la cual permite modelar los métodos de las clases mediante diagramas de actividad.

Figura 4.2. Implementación del procedimiento

La generación de código considera las estructuras de control que son definidas en la gramática y en las regiones de expansión de los diagramas de actividad. Las regiones de expansión son la abstracción del bloque de instrucciones que se realizan dentro de la estructura de control a la que pertenecen, las estructuras de control repetitivas y condicionales contienen regiones de expansión específicas con características específicas de acuerdo al tipo de estructura y se describieron en el capítulo anterior. Fue necesario establecer un punto de comparación entre los diagramas de actividad y el código generado a partir de ellos y como se mencionó en el capítulo 2 la métrica para estructuras de control en diagramas de actividad y código fuente es la complejidad ciclomática (WMCcc).

El esquema que representa la aplicación de las métricas se observa en la figura 4.3, para

obtener la métrica del diagrama de actividad (WMCcc) primero debe elaborarse un diagrama de actividad en la herramienta.

Figura 4.3. Métricas para la generación de código en el modelo de solución

Con el diagrama de actividad se genera automáticamente el código fuente y a partir del código se obtiene la métrica para el código. Con lo anterior se tiene que la herramienta que automatice el procedimiento debe permitir diagramar y/o generar código. Es así que surge el diagrama de casos de uso de la figura 4.4. La métrica representa solo una extensión de lo que se puede realizar con la herramienta, aunque no es necesaria la medición de la complejidad ciclomática para todos los diagramas se decidió que debería ser una parte de la herramienta para

Genera


- 63 -

la realización de las pruebas de generación de código. La métrica integrada en el diagrama permite dar mayor agilidad al proceso de pruebas de generación de código.

Diseñador

Metrica

Generar código

Diagramar

<<extend>>

<<extend>><<extend>>

Figura 4.4. Diagrama de casos de uso de ADCODE

Estos casos de uso son el principio de escenarios de eventos lógicos de lo que puede suceder al utilizar la herramienta. El diseñador modela los métodos de las clases mediante diagramas de actividad y los diagramas son convertidos a código automáticamente.

4.2. Escenarios para los casos de uso de ADCODE

4.2.1. Escenario para el CU1_Diagramar El escenario del CU1_Diagramar en la tabla 4.1 agrupa las opciones que corresponden al diagramador de una forma general.

Tabla 4.1. Escenario de CU1_Diagramar.

Nombre: CU1. Diagramar

Autor: Jazmín Rodríguez Flores

Fecha: 18/abril/2007

Descripción: Permite la creación de un diagrama de actividad del método de una clase.

Actores: Usuario del sistema.

Precondiciones: Obtención de los métodos de las clases que se están modelando

Escenario de éxito: 1. El usuario selecciona el símbolo inicio del menú elementos gráficos 2. El sistema muestra una pantalla para seleccionar el método al cual estará vinculado el

diagrama de actividad. 3. El usuario selecciona el método de la clase. 4. El sistema activa el menú con el resto de los elementos gráficos activos. 5. El actor selecciona un elemento, lo arrastra, lo posiciona y edita sus propiedades.


- 64 -

Escenario de fracaso: 1. El usuario no ordena o relaciona los elementos gráficos correctamente. 2. El sistema envía un mensaje de error con la descripción de la falla. 3. El usuario corrige el error o sale del sistema.

Escenario de fracaso 2: El usuario no teclea correctamente la sentencia asociada al símbolo condicional.

Salida: El diagrama de actividades.

Poscondiciones: El diagrama debe estar sintácticamente correcto.

4.2.2. Escenario para el CU2_GenerarCódigo El escenario del CU2_ GenerarCódigo en la tabla 4.2 se refiere al generador de código de una forma muy general. Tomando en cuenta que el generador de código sólo puede utilizarse si se crea un diagrama con la herramienta ADCODE y dicho diagrama está activo en la ventana actual.

Tabla 4.2. Escenario de CU2_GenerarCódigo. Nombre: CU2_GenerarCódigo

Autor: Jazmín Rodríguez Flores

Fecha: 18/abril/2007

Descripción: Permite la generación de código a partir de un diagrama de actividad que se creó con ADCODE.

Actores: Usuario del sistema.

Precondiciones: Generar el diagrama de actividad con ADCODE.

Escenario de éxito: 1. El usuario selecciona la opción de generar código en el menú. 2. El sistema genera automáticamente el código del método. 3. El usuario abre el archivo para ver el código generado.

Escenario de fracaso: 1. El usuario selecciona la opción de generar código sin haber construido el diagrama de

actividad. 2. El sistema avisa al usuario que debe construir un diagrama antes de generar código. 3. El usuario genera el diagrama o sale del sistema.

Salida: Código en Java

Poscondiciones:


- 65 -

Un conjunto de casos de uso se encuentran en el apéndice A. Al final de ésta tesis. Los diagramas de secuencias de las figuras 4.5 y 4.6 desarrollan los Casos de Uso de las tablas 4.1 y 4.2. En la figura 4.5 se observa que con la herramienta se pueden realizar diagramas dibujando símbolos, moviéndolos, cambiando sus etiquetas y texto. También se establece una relación entre los símbolos.

4.3. Diagramas de Secuencias

4.3.1. Diagrama de secuencias de generar código La figura 4.5 resalta la dependencia que existe entre la creación del diagrama de actividad antes de la generación de código. Sin diagrama de actividad no hay código.

CView CDialogsDlg CDoc Codificar Archivo

Selección del menú generar código

Obtener la ruta a donde va el archivo

Enviar la dirección del archivoCrear Archivo

Abrir Archivo

Enciar ruta de creación

Solicitar Diagrama de actividad

Enviar diagrama de actividades

Generar Código

Enviar código a archivo

Guardar archivo

Mensaje("Código generado con éxito")

Figura 4.5. Diagrama de secuencias de Generar Código

Enviar ruta de creación


- 66 -

4.3.2. Diagrama de secuencias para diagramar

Guardar relación

Cview Menu CDialogsDialog CDoc:obj

Seleccionar simbolo inicial

Seleccionar nuevo Diagrama

Despliegue del menu con el simbolo inicial

Dibujar simbolo Inicio

vincular a método Asociar nuevo texto a elemento grafico

Guardar ElementoElemento inicial guardado

Activar todos los símbolos menos el inicio

Elegir símbolo

Dibujar símbolo elegido

Enviar el elemento a GuardarGuardar elemento

Dibujar simbolos

Mover símbolo

Seleccionar simbolo

Cambiar posición

Elemento a guardarGuardar cambios en posición

Cambiar Texto

Seleccionar símbolo

Cambiar texto

Elemento a guardarGuardar cambios en texto

RelacionarElementos

Seleccionar relacion de símbolos

Activar relación de simbolos

Simbolo origen

Pedir posición

Retornar posición

Simbolo destino

Pedir posición

Retornar posición

Dibujar relación

Elementos relacionados

Figura 4.5. Diagrama de secuencias de diagramar

4.4. Diagramas de clases Con los casos de uso y los diagramas de secuencias se obtuvo una descripción del sistema. Para realizar el diagramador de actividades existe una arquitectura ya definida suite MANGO. ADCODE reutiliza algunas de las clases y respeta la arquitectura existente incluyendo la


- 67 -

reestructuración de clases realizada por [GON04] en las clases derivadas de la clase CGrafico de la figura 4.7 donde los elementos gráficos son modelados mediante el patrón de diseño Strategy2.

Figura 4.7. Diagrama de clases de ADCODE

En las clases definidas en la figura 4.7 se representa la gramática visual relacional. Los

símbolos terminales de la gramática corresponden a la clase CEstadosEstrategiaDA que pertenecen a la clase CDiagrama. El conjunto finito de relaciones entre símbolos se representa por la clase CTransición que hereda de la clase CRelacionesEstarategiaDA quien a su vez pertenece a la clase CDiagrama. Es así como se conforma el diagramador, parte de la gramática

2 La definición del patrón de diseño Strategy se encuentra en el libro de Gamma. [GAM95].

CListIterator CNullIterator

CObjeto

CInicio CFin

CRelacion

CTransicion CTransicionCTRUE CTransicionCFALSE

CDiagrama

DiagramaActividad

CGraficoCIterator

Cliente

aStrategy

Contexto

obj:str

obj:ctx

GenerarCodigo

CActividad CCondicional CMerge CConc_ini CConc_fin

ParserMetodosCWccDA

CEstadosEstrategiaDA CRelacionesEstrategiaDA

CView

CGenerador

CCommandLButtonDown

CCommandLButtonUp

CCommandLButtonDbClk

CCommandKeySupr

CCommand

CDocument


- 68 -

visual relacional se evaluó aquí mediante la clase CValidar con el método validarTransicion (CEstadosEstrategiaDA *figuraOrigen, CEstadosEstrategiaDA *figuraDestino), en éste método se analizan las transiciones que son dibujadas entre los símbolos del diagrama de actividad. Por ejemplo el símbolo inicio sólo puede tener transiciones de salida, nunca de entrada de acuerdo a la gramática visual relacional; el símbolo final sólo puede recibir transiciones de entrada, nunca debe tener transiciones de salida; el símbolo actividad siempre deberá tener sólo una transición de entrada y una salida; por último los símbolos condicionales tendrán diferente número de entradas y salidas de acuerdo a la tabla 3.1 del capítulo anterior.

El objeto m_diagrama es una estructura de datos tipo lista que contiene todos los

elementos del diagrama de actividad que fueron dibujados. El generador de código utiliza al objeto (m_diagrama) del tipo de la clase CDiagramaDA

creado por el diagramador (ver figura 4.8). A partir de m_diagrama se obtienen las relaciones entre símbolos y se crea una tabla de transiciones (objTablaTransiciones). La tabla de transiciones contiene los elementos gráficos que son unidos por el símbolo gráfico transición. La especificación contiene del estado origen su número de nodo en la lista diagrama y el tipo de elemento que representa el número de transiciones de entrada y de salida. Del estado destino contiene su número de nodo en la lista diagrama, el tipo de elemento que es, el número de transiciones de entrada y de salida. Y de la transición su número de nodo en la lista y el tipo de transición que es (TRUE, FALSE o sin etiqueta). El objeto objTablaTransiciones se creo con la finalidad de realizar una consulta más rápida sobre las relaciones entre los objetos y agilizar la generación de código debido a que era muy tardado realizar una consulta sobre el diagrama original (m_diagrama) y realizar las búsquedas de esos elementos cada vez.

CADCODEDoc

CDiagramaDA0..1

1

+m_diagrama

CListaTransicion

CGeneradorCDA0..1

1 -diagramaLocal

1

1

-objTablaTransiciones

0..1

1

0..1

1

1

1

Figura 4.8. Clases principales de la generación de código con diagramas de actividad.

La tabla 3.1 del capítulo anterior es la base para encontrar las estructuras de control, la

tabla se transforma en una serie de condiciones analizadas en los métodos de la clase de CGenerador. El código en la figura 4.9 pertenece a la búsqueda de los elementos de la estructura del flujo de control del capítulo anterior en el objeto objTablaTransiciones. La condición evaluada objNodoTemporal->getTipoO () revisa el elemento origen de la tabla de transiciones y dependiendo del símbolo lo procesa diferente de acuerdo a la gramática.


- 69 -

Figura 4.9. Código de ADCODE que procesa cada símbolo para la generación de código La finalidad de la tabla de transiciones es realizar consultas acerca de los elementos del

diagrama para generar su código, sin necesidad de realizar búsquedas sobre el diagrama original, esto cada vez que se requiera un dato para determinar la estructura del flujo de control en la generación de código.

Los valores que se llenan en la tabla de transiciones son los siguientes:

a) nodoT: Número de transición. b) numEtiqueta: Describe el tipo de transición (0: true, 1: false, 2: ninguna). c) nodoO: Nodo origen de la transición. d) nodoD: Nodo destino de la transición. e) tipoO: Tipo origen de la transición (0: inicio,1: actividad, 2:final, 3: condicional,4: merge) f) tipoD: Tipo destino de la transición. g) numTinO: Número de transiciones de entrada al símbolo origen. h) numToutO: Número de transiciones de salida del símbolo destino. i) numTinD: Número de transiciones de entrada al símbolo destino. j) numToutD: Número de transiciones de salida del símbolo destino.

switch (objNodoTemporal->getTipoO()){//Busca el símbolo inicial /////////////Para la generación de código case 0: if (!simboloInicial(pFigura))return false; break; case 1: simboloActividad(pFigura); break; case 2: simboloFinal(pFigura); break; case 4: if(simboloMerge(pFigura,objNodoTemporal)==2) { int ultimoNodo=objLOrigen.GetN(); destino=objLOrigen.ObtenerNodo(ultimoNodo); objLOrigen.BorraNodoActual(ultimoNodo); ife=true; } break; case 5: simboloBifurcacion(pFigura,objNodoTemporal); break; case 3: if(simboloCondicional(pFigura,objNodoTemporal)==3)//Si es do_While { CNodoTransicion* nodoTDW= eliminarTansicionVaciaD_W(origen); //busca una c--TRUE-->w y toma el valor c--FALSE--> XX destino=nodoTDW->getNodoD(); tipoD=nodoTDW->getTipoD(); } break; }//Fin del switch


- 70 -

En el siguiente ejemplo de la figura 4.10 se especifica el llenado de la tabla de transiciones.

• Los números del 1 al 6 corresponden los elementos gráficos del diagrama de actividad. • Los números en negritas del 7 al 12 corresponden a las transiciones que unen a los

símbolos. Nótese que la transición 10 es de tipo TRUE y la transición 8 es FALSE. La primera transición con el número 7 corresponde a la unión del símbolo inicio con el símbolo condicional.

Figura 4.10. Diagrama de actividad de una estructura IF_ELSE Si se analiza la transición etiquetada con el número 7 se observa: nodoT: 7 numEtiqueta: 2 porque la transición no está etiquetada. nodoO: El nodo origen es el símbolo inicio etiquetado con 1. nodoD: El nodo destino es una condicional etiquetada con el número 2. tipoO: El tipo para el inicio es 0. tipoD: El tipo para la condicional es 3. numTinO: El número de transiciones de entrada al origen es 0. numToutO: El número de transiciones de salida del origen es 1. numTinD: El número de transiciones de entrada al destino es 1. numToutD: El número de transiciones de salida del destino es 2. La operación se repite para cada transición del diagrama hasta obtener todas las transiciones del diagrama como se observa en la tabla 4.3. El nodoT=7 corresponde al primer renglón de la tabla.

Tabla 4.3. Tabla de transiciones a) b) c) d) e) f) g) h) i) j) 7 2 1 2 0 3 0 1 1 2 8 1 2 4 3 1 1 2 1 1 9 2 4 3 1 4 1 1 2 1 10 0 2 5 3 1 1 1 1 1 11 2 5 3 1 4 1 1 2 1 12 2 3 6 4 3 2 1 1 0

1 2

3

4

5

6

7

8

9

10

11

12


- 71 -

Ya que se programó la herramienta diagramadora que valida y analiza la gramática se debe conocer como utilizarla y eso se detalla a continuación. La tabla se transiciones es importante porque a partir de ella se genera el flujo de control del código.

4.5. Utilización de la herramienta

4.5.1. Diagramador En el ambiente de trabajo de ADCODE se observa la barra de herramientas del diagramador. Que permite diseñar un diagrama de actividades. El menú herramientas que permite acceder a la métrica del diagrama de actividades y del código en Java.

Figura 4.11. Pantalla de trabajo de ADCODE.

En la figura 4.12 se observa parte de la barra de herramientas de ADCODE donde se

representan elementos de la gramática.

Figura 4.12 Símbolos dibujados por ADCODE que representan a los elementos terminales de la gramática.

La tabla 4.4 contiene una descripción de los elementos que integran la barra de herramientas de ADCODE.


- 72 -

Tabla 4.4. Elementos que integran la herramienta ADCODE

Símbolo

Nombre del símbolo Descripción

Apuntador El símbolo apuntador sirve para seleccionar y mover las figuras

Símbolo inicial Es el inicio del diagrama de actividad. En éste símbolo se configuran las propiedades de nombre de la clase del método que se modela.

Símbolo final Sirve para indicar el final del modelado de un método y para declarar el retorno de valores.

Símbolo transición Sirve para unir símbolos gráficos. Se usa seleccionándolo en la barra de herramientas después debe hacer clic izquierdo en el elemento inicial y soltar el botón sobre el elemento que será el destino. La transición puede estar etiquetada con TRUE o FALSE o sin etiqueta.

Símbolo actividad Sirve para expresar sentencias de control como instrucciones de lectura o escritura. Puede contener código de algún lenguaje en particular.

Símbolo condicional Se utiliza para modelar estructuras de repetición y selección. Dentro de él se escribe la condición que se desea evaluar. Al hacer clic izquierdo con el ratón sobre el documento se crea el símbolo condicional y el símbolo merge automáticamente de acuerdo a la gramática. El símbolo merge no lleva texto condicional dentro del símbolo.

Símbolo nota Se encuentra en la barra de herramientas. Sirve para agregar

comentarios.

Símbolo de generación de código Java

Al hacer clic sobre éste elemento se genera el código Java. El archivo es generado en el directorio actual o donde se guardó el diagrama.

En el anexo B se describen las propiedades configurables de los elementos gráficos en el

momento de su creación.

Con el símbolo condicional se debe modelar las estructuras de selección, y repetición. Las estructuras condicionales se representan por el IF y el IF_ELSE. La estructura Switch no se consideró en el presente trabajo. La figura 4.13 muestra el modelado de la estructura IF.

Figura 4.13. Modelado de la estructura IF con ADCODE


- 73 -

La figura 4.14 muestra el modelado para la estructura de control IF_ELSE. Puede

observarse en la figura que se retorna un valor en el símbolo final que aparece como una etiqueta al lado del símbolo final.

Figura 4.14. Modelado de la estructura IF_ELSE con ADCODE

Las estructuras repetitivas están representadas por: WHILE, FOR y DO_WHILE. El

modelado de la estructura WHILE se representó en la figura 4.15 y en la figura 4.16 se representó la estructura FOR. Debe notarse que el modelado es similar y la diferencia radica solo en el contenido de la condición a ser evaluada.

Figura 4.15. Modelado de la estructura FOR con ADCODE


- 74 -

Figura 4.16. Modelado de la estructura WHILE con ADCODE

El modelado de la estructura de control DO_WHILE con ADCODE se representa en la figura 4.17.

Figura 4.17. Modelado de la estructura DO_WHILE con ADCODE En las figuras 4.13 a la 4.17 se observa el modelado de las estructuras básicas de selección

y repetición. En ellas se encuentra el símbolo merge <m> (definido en la gramática visual relacional del capítulo 3) que pertenece a la clase CcondicionDA y es creado al mismo tiempo que el símbolo condicional <c>. El símbolo condicional es un elemento que divide el flujo de control en dos ramificaciones que después deberán ser unidas mediante el símbolo merge para la generación de código.

4.5.2. Generación de código La generación de código se realiza con el diagrama de actividad abierto. Puede ser uno recién creado o uno almacenado. La opción de creación de código se observa en la figura 4.18. El botón de creación de código se encuentra en la barra de herramientas del diagramador. Los mensajes de error en la generación de código son descritos en el anexo B3.


- 75 -

Figura 4.18. Botón de generación de código Java a partir de diagramas de actividad.

4.5.3. Herramientas En el menú herramientas de la figura 4.19 se puede observar dónde calcular la métrica de complejidad ciclomática para diagramas de actividad.

Figura 4.19. Métrica de complejidad ciclomática para diagramas de actividad.

La complejidad ciclomática también se calcula para código Java como lo muestra la figura 4.20. Para comparar la complejidad ciclomática del diagrama de actividad con el código generado por ADCODE.

Figura 4.20. Cálculo de la complejidad ciclomática para código Java.

Después de ejecutar el menú herramientas de ADCODE el resultado es mostrado en un cuadro de diálogo como el de la figura 4.21 CDC_MIN es la métrica de cuentas de decisión (DE) y complejidad ciclomática es la complejidad ciclomática del código o del diagrama.

Figura 4.21. El cuadro de diálogo que muestra la medida de complejidad ciclomática.


- 76 -

4.6. Conclusiones del capítulo Para realizar el diagramador se disponía de una arquitectura ya definida, sólo se agregaron nuevos símbolos para ser dibujados. Para la implementación de la gramática visual relacional se requirió de dos clases. Una que validar las transiciones entre elementos (CValidar) al momento de su creación en el diagrama y otra que buscara las estructuras de control en el diagrama (CGeneradorCDA) y generara su código. El texto que enriqueció los diagramas de actividad es del tipo del lenguaje Java por lo que no fue necesario hacer transformación sólo se copió y pegó en el lugar adecuado. Además para verificar una correspondencia entre el código generado y la gramática visual relacional como se vio en el capítulo 2, se creó una clase llamada CWccDA cuyo método CWccDA::ComplejidadJava (CString nombreArchivo) mide la complejidad ciclomática del archivo en Java que recibe como parámetro. Y el método CWccDA::ComplejidadDiagramaActividad(CLista objLista)se encarga de calcular la complejidad ciclomática del diagrama de actividad que está abierto en pantalla. Una vez concluida la herramienta se realizaron las pruebas del procedimiento utilizando la herramienta. Además se realizaron pruebas sobre la lógica del sistema utilizando valores de prueba para revisar la lógica del diagrama de actividad y comparar contra la lógica del código fuente generado. Eso se describe en el capítulo siguiente para el cual se utilizó un estándar de pruebas de la IEEE.


77

CAPÍTULO 5 En este capítulo se describe la evaluación experimental 5.1 Introducción 5.2 Plan de pruebas 5.3 Especificaciones de casos de prueba 5.4 Especificación de procedimientos de prueba 5.5 Reporte de incidentes de prueba 5.6 Reportes de resumen de prueba

Pruebas de la herramienta que valida el procedimiento de transformación

Capítulo 5. Pruebas de la herramienta

- 78 -

Capítulo 5. Pruebas de la herramienta que valida el procedimiento de transformación

5.1. Introducción El plan de pruebas permite dirigir un conjunto de verificaciones que se le realizarán al sistema. Usa los elementos: diagramas de actividad, código generado y herramienta como elementos de prueba. Éste capítulo presenta el plan de pruebas basado en el estándar 829 de la IEEE [IEEE98]. La convención de nombres se utiliza durante éste capítulo para identificar los documentos del plan de pruebas y aparece en la parte superior derecha de cada hoja de éste capítulo.

5.2. Plan de pruebas

5.2.2. Convención de nombres El presente plan de pruebas se basa en el estándar [IEEE98]. A continuación se describen las claves para los documentos del plan de pruebas. El documento se identifica con la siguiente convención de nombres:

• Clave del sistema: ADCODE corresponde al nombre del procedimiento activity diagrams to code.

• Laboratorio: El laboratorio que se describe es el Laboratorio de Ingeniería de Software (LIS).

• Los documentos se identifican con una clave:

PP Plan de pruebas CP Especificaciones de casos de prueba EP Especificación de procedimientos de prueba RI Reporte de incidentes de prueba RR Reportes de resumen de prueba

• Número consecutivo: es el número obtenido para cada prueba y documento.

Para describir el primer documento del plan de pruebas se utilizará el siguiente número corresponde con la convención de nombres

ADCODE LIS PP 01

5.2.3. Elementos de prueba

• Diagramas de actividad. • Código generado. • Herramienta.

ADCODE LIS CP01 Generación de código a partir de diagramas de actividad UML

- 79 -

5.2.4. Características que serán probadas Se probarán los diagramas de actividad que representan los métodos de las clases con las siguientes características:

• Que existan estructuras de secuencia, repetición o selección dentro del diagrama de actividad.

• Las conexiones de los elementos que integran el diagrama de actividad serán probadas por la herramienta generadora de diagramas.

Código generado:

• Se probará que el código generado tenga correspondencia con el diagrama de actividad. • Probar que compile.

Herramienta: Es el medio para probar la generación de código.

5.2.5. Características que no se probarán Diagramas de actividad:

• No se probará que los diagramas de actividad estén semánticamente correctos. Código generado:

• Probar la lógica del código

5.2.6. Enfoque El procedimiento de transformación será probado con la herramienta. Probando el código existente contra el generado.

5.2.7. Criterios de éxito o fracaso

5.2.7.1. Los criterios de éxito

El éxito de la transformación es generar código que compile y tenga correspondencia con el diagrama de actividad.


- 80 -

5.2.7.2. Los criterios de fracaso Se consideraron fracasos los archivos de código que no compilaron y que fueron generados con ADCODE a partir de diagramas de actividad elaborados con las reglas de producción definidas en la gramática visual relacional la cual está definida en el capítulo 3 y las etiquetas definidas para la construcción del diagrama.

5.2.8. Criterios de la suspensión y requisitos para la reanudación Detectar errores en el mapeo de la herramienta.

5.2.9. Entregables de pruebas Los documentos entregables son los siguientes

a) Plan de pruebas b) Especificaciones de casos de prueba d) Especificación de procedimientos de prueba e) Reporte de incidentes de prueba f) Reportes de resumen de prueba

5.2.10. Tareas de pruebas

1. Seleccionar el caso de estudio: el sistema simulador del cajero automático. 2. Seleccionar los casos de prueba. 3. Realizar el procedimiento de prueba. 4. Comparar resultados 5. Obtener conclusiones.

5.2.11. Necesidades del entorno Los sistemas elaborados en Visual C++ trabajan en el sistema operativo Windows. RAM de 256 como mínimo. El sistema está instalado en un equipo marca Acer con las siguientes características:

• Intel(R) Pentium(R) 4 CPU 3.00GHz • Velocidad de bus 800 MHz • Memoria RAM: 1024 MB • Disco duro: 74.53 GB


- 81 -

5.2.12. Riesgos y contingencias Riesgos:

• Entrega retrasada del sistema. • Que los diagramas de actividad del caso de prueba estén mal elaborados.

5.2.13. Aprobaciones Para implementar el presente plan de pruebas, es necesario que tenga la aprobación del director de tesis, el Dr. Máximo López Sánchez.

5.3. Especificaciones de casos de prueba (CP)

Se seleccionó como caso de estudio un sistema simulador de cajero automático (ATM,Automated Teller Machine) del departamento de matemáticas y ciencias de la computación (http://www.math-cs.gordon.edu/courses/cs211/ATMExample/) por el profesor Rusell C. Bjork en la materia de desarrollo de software orientado a objetos. Este sistema proporciona funcionalidades como las mostradas en la figura 1 y consisten en iniciar sistema (System startup), cerrar sistema (System Shutdown), iniciar sesión (Session), realizar transacciones (Transaction), retirar (Withdrwal), depositar (Deposit), transferir (Transfer) y consultar (Inquiry).

Figura 5.1. Casos de uso del caso de estudio: Cajero automático. [BJO04]


- 82 -

El sistema completo está desarrollado en Java y para el lenguaje C++ estándar no está completo. El código posee documentación UML de los diagramas de clases, interacción, estados, entre otros.

Los diagramas de clases sirven para representar los métodos de las clases. Los diagramas de clases (ver figura 5.2) del cajero permiten conocer la estructura del sistema.

Figura 5.2. Diagrama de clases del cajero automático. [BJO04]


- 83 -

La tabla 5.1 describe los casos de prueba que fueron seleccionados de las clases del cajero automático [BJO04]. Las características corresponden al tipo de flujo y el tipo de estructuras que serán probadas por método.

Tabla 5.1. Casos de prueba definidos para la herramienta ADCODE

Caso de prueba

Clase método Características

CP1 Card Card( ) Flujo secuencial y retorno de valores

getNumber( ) Flujo secuencial sin retorno de valores.

CP2 Status toString( ) Contiene condicionales anidadas.

CP3 Log Log ( ) Sólo contiene la declaración del método.

LogSend( ) Flujo secuencial LogResponse ( ) Flujo secuencial CP4 CustomerConsole readPin ( ) Contiene flujos secuenciales

y condiciones.

readMenuChoice ( ) Estructuras de repetición y condición.

readAmount( ) Flujo secuencial y condiciones con retorno de valor.

CP5 ReceiptPrinter PrintReceipt( ) Contiene estructuras de repetición.


- 84 -

5.4. Especificación de procedimientos de prueba (EP) Los pasos a seguir en la el procedimiento de prueba son los siguientes:

1. Definir los casos de prueba que contengan estructuras básicas de secuenciación, repetición y selección para ser modeladas con diagramas de actividad: En el ADODE-LIS-CP-00 se definieron los casos de prueba CP1, CP2, CP3, CP4, CP5, CP6, CP7. 2. Obtener el código original en java de los casos de prueba que se va a modelar. 3. Generar el diagrama de actividad que corresponde a los métodos de los casos de prueba con la herramienta ADCODE. 4. Generar el código con la herramienta ADCODE. 5. Evaluar los resultados obtenidos con el menú herramientas de la herramienta ADOCODE (éstas herramientas consisten en el cálculo de la complejidad ciclomática para diagramas de actividad y código en java) 6. Comparar los números obtenidos. 7. Revisar la sintaxis 8. Prueba manual de la lógica del diagrama

ADCODE LIS EP01 Generación de código a partir de diagramas de actividad UML

- 85 -

5.4.1. EP01. Clase Card: Métodos Card( ) y getNumber( ) Paso 1: El paso uno del procedimiento de prueba fue realizado en la tabla 5.1. Paso 2. El código original de la clase Card fue extraído de [BJO04] se encuentra en la figura 5.3

Figura 5.3. Código de la clase Card( ) obtenido de [BJO04]

Pasos 3 y 4. Modelado y generación con ADCODE del código del método Card ( ) se observa en la figura 5.4. El método getNumber( ) se observa en la figura 5.5 Clase Card: método Card ( )

a. diagrama de actividad b. Código generado con ADCODE

Figura 5.4. Modelado y generación de código del método Card ( )

public class Card { /** Constructor * * @param number the card number */ public Card(int number) { this.number = number; } /** Accessor for number * * @return the number of the card */ public int getNumber() { return number; } /** Card number encoded on the card */ private int number; }

/*Código del método generado por ADCODE*/ public Card (int number){ this.number=number; }


- 86 -

Clase Card: Método getNumber( )

a. Diagrama de actividad b. Código del método generado por ADCODE

Figura 5.5. Modelado y generación de código del método getNumber( ) Paso 5. El cálculo de la complejidad ciclomática en ADCODE sirve para medir la

cantidad de estructuras de control que son generadas en código Java y poder establecer una comparación contra el diagrama de actividad en cuanto a las estructuras generadas.

Tabla 5.2. Valores obtenidos para la medida de la complejidad ciclomática.

Nombre del método

Código original Código generado con ADCODE Diagrama de actividad

Método Card ( )

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

Método getNumber( )

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

Paso 6. En la tabla 5.2 se observa que el número de estructuras de control en el código

original, en el código generado con ADCODE y en el diagrama de actividad es el mismo. Paso 7. Se implementó con ECLIPSE debido a que los errores de sintaxis son marcados

de inmediato y se puede observar el resultado en la figura 5.6. Sólo marca como warning la declaración de la librería “java.io.*” debido a que no es utilizada en la clase.

/*Código del método generado por ADCODE*/ public int getNumber( ){ return number; }


- 87 -

Figura 5.6. Revisión de sintaxis con ECLIPSE

Paso 8. Se creó una clase main para realizar la ejecución del código.

Figura 5.7. Pruebas de la ejecución del código

Se probó el diagrama de actividad y el código generado mediante etiquetas en el sistema que indiquen la instrucción que se está realizando y realizar pruebas de escritorio. Prueba manual del diagrama de actividad

1. Se inicializa el constructor con un valor 5. 2. El atributo number es inicializado. 3. Se invoca al método para obtener el atributo y se obtiene el valor

Ejecución del programa: Se agregó la impresión de mensajes en la ejecución de cada instrucción y los mensajes obtenidos se muestran a continuación:

Se instancia el objeto: se ejecutó la instrucción this retorna el valor imprime el resultado: 5


- 88 -

5.4.2. EP02. Clase Status: Método toString( )

Paso 1: El paso uno del procedimiento de prueba fue realizado en la tabla 5.1.

Paso 2. El código original de la clase Status fue extraído de [BJO04] se encuentra en la figura 5.8

Figura 5.8. Código de la clase Status obtenido de [BJO04]

Pasos 3 y 4. Modelado y generación con ADCODE del código del método toString() se observan en la figura 5.9 y 5.10. Clase Status: método toString ( )

Figura 5.9. Diagrama de actividad del método toString( )

public abstract class Status { public String toString() { if (isSuccess()) return "SUCCESS"; else if (isInvalidPIN()) return "INVALID PIN"; else return "FAILURE " + getMessage(); } public abstract boolean isSuccess(); public abstract boolean isInvalidPIN(); public abstract String getMessage(); }


- 89 -

Figura 5.10. Generación de código del método toString ( ) con ADCODE

Paso 5. El cálculo de la complejidad ciclomática en ADCODE sirve para medir la

cantidad de estructuras de control que son generadas en código Java y poder establecer una comparación contra el diagrama de actividad en cuanto a las estructuras generadas.


Nombre del método Código original Código generado con ADCODE Diagrama de actividad Método toString ( ) CDC_MIN= 2

CC= 3 CDC_MIN= 2 CC= 3

CDC_MIN= 2 CC= 3


original, en el código generado con ADCODE y en el diagrama de actividad es el mismo. Paso 7. Se realizó con ECLIPSE debido a que los errores de sintaxis son marcados de

inmediato y se puede observar el resultado en la figura 5.11. Sólo marca como warning la declaración de la librería “java.io.*” debido a que no es utilizada en la clase.

/*Código del método generado por ADCODE*/ public String toString( ){ if( isSuccess( )){ return "SUCCESS"; } else{ if( isInvalidPIN( )){ return "INVALID PIN"; } else{ return "FAILURE " + getMessage(); } } }


- 90 -


Paso 8. Se creó una clase main para llevar a cabo la ejecución del código. Pero no se

puede instanciar un objeto de una clase abstracta en Java. Por lo tanto se somete a pruebas de escritorio sobre el método. Se realizaron pruebas con los siguientes valores: isSuccess con valores TRUE y FALSE e isvalidPIN() con valores de TRUE, FALSE y no-evaluado. Obteniendo la tabla 5.4. Donde el valor No-Evaluado se debe a que cuando la función isSucess( ) devuelve un valor TRUE y la función isInvalidPIN( ) nunca es invocada.

Tabla 5.4. Valores de prueba para la función toString ( )

isSucess

TRUE FALSE TRUE -- Retorna “Invalid PIN” FALSE -- Retorna “FAILURE”

IsInvalidPIN

No-evaluado Retorna “SUCCESS”


- 91 -

5.4.3. EP03. Clase LOG: Métodos Log ( ), LogSend ( ) y LogResponse ( ) Paso 1: El paso uno del procedimiento de prueba fue realizado en la tabla 5.1.

Paso 2. El código original de la clase Log fue extraído de [BJO04] se encuentra en la figura 5.12

Figura 5.12. Código de la clase Log obtenido de [BJO04]

Pasos 3 y 4. Modelado y generación con ADCODE del código de los métodos Log ( ), LogSend ( ) y LogResponse ( ) se observan en la figura 5.13, 5.14 y 5.10. Clase Log: método Log ( )

Figura 5.13. Diagrama de actividad del método Log ( )

public class Log{ public Log() { } /** Log the sending of a message to the bank * * @param message the message to be logged */ public void logSend(Message message) { Simulation.getInstance().printLogLine("Message: " + message.toString()); } /** Log a response received from a message * * @param status the status object returned by the bank in response */ public void logResponse(Status response) { Simulation.getInstance().printLogLine("Response: " + response.toString()); } }

import java.io.*; public class Log{ /*Código del método generado por ADCODE*/ public Log( ){ } }


- 92 -

Clase Log: método LoSend ( )

Figura 5.14. Modelado y generación de código del método LogSend ( ) de la clase Log mediante ADCODE Clase Log: método LoResponse ( )

Figura 5.15. Modelado y generación de código del método LogResponse ( ) de la clase Log mediante ADCODE

Paso 5. El cálculo de la complejidad ciclomática en ADCODE sirve para medir la

cantidad de estructuras de control que son generadas en código Java, y poder establecer una comparación contra el diagrama de actividad en cuanto a las estructuras generadas.

/* Código generado por ADCODE */ import java.io.*; public class Log{ /*Código del método generado por ADCODE*/ public void logSend(Message message){ Simulation.getInstance().printLogLine("Message: " + message.toString()); } }

/* Código generado por ADCODE */ import java.io.*; public class Log{ /*Código del método generado por ADCODE*/ public void logResponse(Status response){ Simulation.getInstance().printLogLine("Response: " + response.toString()); } }


- 93 -


Nombre del método Código original Código generado con ADCODE Diagrama de actividad Método Log CDC_MIN= 0


CDC_MIN= 0 CC= 1

Método logSend ( )

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

Método logResponse( )

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

CDC_MIN= 0 CC= 1

Paso 6. En la tabla 5.5 se observa que el número de estructuras de control en el código original, en el código generado con ADCODE y en el diagrama de actividad es el mismo.

Paso 7. Se realizó con ECLIPSE debido a que los errores de sintaxis son marcados de

inmediato y se puede observar el resultado en la figura 5.16.


Paso 8. Se realizaron pruebas de escritorio acerca del diagrama y del código generado con

los valores de la tabla 5.6 y se obtuvieron los siguientes resultados.

Tabla 5.6. Valores de prueba para la clase Log ( )

Método Parámetro recibido Valor impreso en pantalla Log -- -- LogResponse response=“SUCCESS” Imprime “SUCCESS” LogMessage response= “INVALID

PIN” Imprime “INVALID PIN”


- 94 -

5.4.4. EP04. Clase CustomerConsole: Métodos readPin ( ), readMenuChoice ( ) y readAmount ( ) Paso 1: El paso uno del procedimiento de prueba fue realizado en la tabla 5.1. Paso 2. El código original de la clase CustomerConsole fue extraído de [BJO04] se encuentra en la figura 5.17

Figura 5.17. Código de la clase CustomerConsole obtenido de [BJO04]

class CustomerConsole{ public int readPIN(String prompt) throws Cancelled { Simulation.getInstance().clearDisplay(); Simulation.getInstance().display(prompt); Simulation.getInstance().display(""); String input = Simulation.getInstance().readInput(Simulation.PIN_MODE, 0); Simulation.getInstance().clearDisplay(); if (input == null) throw new Cancelled(); else return Integer.parseInt(input); } public synchronized int readMenuChoice(String prompt, String[] menu) throws Cancelled { Simulation.getInstance().clearDisplay(); Simulation.getInstance().display(prompt); for (int i = 0; i < menu.length; i ++) Simulation.getInstance().display((i+1) + ") " + menu[i]); String input = Simulation.getInstance().readInput(Simulation.MENU_MODE, menu.length); Simulation.getInstance().clearDisplay(); if (input == null) throw new Cancelled(); else return Integer.parseInt(input) - 1; } public synchronized Money readAmount(String prompt) throws Cancelled { Simulation.getInstance().clearDisplay(); Simulation.getInstance().display(prompt); Simulation.getInstance().display(""); String input = Simulation.getInstance().readInput(Simulation.AMOUNT_MODE, 0); Simulation.getInstance().clearDisplay(); if (input == null) throw new Cancelled(); else { int dollars = Integer.parseInt(input) / 100; int cents = Integer.parseInt(input) % 100; return new Money(dollars, cents); } } }


- 95 -

Pasos 3 y 4. Modelado y generación con ADCODE del código de los métodos readPin (), readMenuChoice (), readAmount () se observan en las figuras 5.18, 5.19 y 5.20. Clase CustomerConsole: método readPin ( )

a. diagrama de actividad

b. Código generado con ADCODE

Figura 5.18. Modelado y generación de código del método readPIN ( )

import java.io.*; public class CustomerConsole{ /*Código del método generado por ADCODE*/ public int readPIN( ){ Simulation.getInstance().clearDisplay(); Simulation.getInstance().display(prompt); Simulation.getInstance().display(""); String input = Simulation.getInstance().readInput(Simulation.PIN_MODE, 0); Simulation.getInstance().clearDisplay(); if( input == null){ throw new Cancelled(); } else{ return Integer.parseInt(input); } } }


- 96 -

Clase CustomerConsole: Método readMenuChoice( )

a. Diagrama de actividad elaborado con ADCODE

b. Código del método generado por ADCODE

Figura 5.19. Modelado y generación de código del método readMenuChoice( )

import java.io.*; public class CustomerConsole{ /*Código del método generado por ADCODE*/ public readMenuChoice(String prompt, String[] menu) throws Cancelled{ Simulation.getInstance().clearDisplay(); Simulation.getInstance().display(prompt); for( int i = 0; i < menu.length; i ++){ Simulation.getInstance().display((i+1) + ") " + menu[i]); } String input = Simulation.getInstance().readInput(Simulation.MENU_MODE, menu.length); Simulation.getInstance().clearDisplay(); if( input == null){ throw new Cancelled(); } else{ return Integer.parseInt(input) - 1; } } }


- 97 -

Clase CustomerConsole: Método readAmount( )

a. Diagrama de actividad

b. Código del método generado por ADCODE

Figura 5.20. Modelado y generación de código del método readAmount( )

public class CustomerConsole{ /*Código del método generado por ADCODE*/ public synchronized Money readAmount(String prompt) throws Cancelled{ Simulation.getInstance().clearDisplay(); Simulation.getInstance().display(prompt); Simulation.getInstance().display(""); String input = Simulation.getInstance().readInput(Simulation.AMOUNT_MODE, 0); Simulation.getInstance().clearDisplay(); if( input == null){ throw new Cancelled( ); } else{ int dollars = Integer.parseInt(input) / 100; int cents = Integer.parseInt(input) % 100; return new Money(dollars, cents); } } }


- 98 -

Paso 5. El cálculo de la complejidad ciclomática en ADCODE sirve para medir la cantidad de estructuras de control que son generadas en código Java y poder establecer una comparación contra el diagrama de actividad en cuanto a las estructuras generadas.

Tabla 5.7. Valores obtenidos para la medida de la complejidad ciclomática. Nombre del método Código original Código generado con ADCODE Diagrama de actividad Método readPin ( ) CDC_MIN= 1


CDC_MIN= 1 CC= 2

Método readMenuChoice ( )

CDC_MIN= 2 CC= 3

CDC_MIN= 2 CC= 3

CDC_MIN= 2 CC= 3

Método readAmount ( )

CDC_MIN= 1 CC= 2

CDC_MIN= 1 CC= 2

CDC_MIN= 1 CC= 2

Paso 6. En la tabla 5.7 se observa que el número de estructuras de control en el código original, en el código generado con ADCODE y en el diagrama de actividad es el mismo.

Paso 7. Se realizó con ECLIPSE debido a que los errores de sintaxis son marcados de

inmediato y se puede observar el resultado en la figura 5.21 y 5.22. La advertencia que se observa es debido a que necesita del paquete simulation, que para efectos de ésta prueba no fue anexado a los casos de prueba debido a que no está disponible para descarga. Se observa que el código original y el código generado por ADCODE tienen las mismas advertencias.

Figura 5.21. Comprobación de sintaxis del código original en Eclipse


- 99 -

Figura 5.22. Comprobación de sintaxis del código generado por ADCODE del método readPin( )

Figura 5.23. Comprobación de sintaxis del código original con ECLIPSE del método readMenuChoice( )

Figura 5.24. Comprobación de sintaxis del código generado por ADCODE del método readMenuChoice()


- 100 -

Figura 5.25. Comprobación de sintaxis del código original con ECLIPSE del método readAmount( )

Figura 5.26. Comprobación de sintaxis del código generado por ADCODE del método readAmount( )

Se puede observar que en la substitución del código original por el código generado de forma automática por ADCODE se obtuvo el mismo resultado de marcas de sintaxis. Debido a que ADCODE identifica las estructuras de control modeladas en diagramas de actividad y no la lógica del programador.


- 101 -

Paso 8. Se realizaron pruebas de escritorio acerca del diagrama y del código generado con los valores de la tabla 5.8 y se obtuvieron los siguientes resultados.

Tabla 5.8. Valores de prueba para la clase Customer Console ( )

Método Parámetro recibido Valor impreso en pantalla readPin Input = “1234” Devuelve el valor entero del

número tecleado y es desplegado en pantalla en forma de texto.

readMenuChoice Menú =“CASH” Input=2//Es la opción seleccionada del menú

Imprime en pantalla letra a letra “CASH” Devuelve la cantidad entera de input.

readAmount input= null input= “20.00”

Cancela la operación Retorna la cadena recibida en formato entero.


- 102 -

5.4.5. EP05. Clase ReceiptPrinter: Métodos PrintReceipt ( ) Paso 1: El paso uno del procedimiento de prueba fue realizado en la tabla uno.

Paso 2. El código original de la clase ReceiptPrinter fue extraído de [BJO04] se encuentra en la figura 5.27

Figura 5.27. Código de la clase Card ( ) obtenido de [BJO04]

Pasos 3 y 4. Modelado y generación con ADCODE del código del método printReceipt ( ) se observa en la figura 5.28 y 5.29. Clase ReceiptPrinter: método printReceipt ( )

Figura 5.28. Modelado con la herramienta ADCODE del método printReceipt( )

public class ReceiptPrinter { public void printReceipt(Receipt receipt) { Enumeration receiptLines = receipt.getLines(); // Animate the printing of the receipt while (receiptLines.hasMoreElements()) { Simulation.getInstance().printReceiptLine(((String) receiptLines.nextElement())); } } }


- 103 -

Figura 5.29. Generación de código con la herramienta ADCODE del método printReceipt() Paso 5. El cálculo de la complejidad ciclomática en ADCODE sirve para medir la cantidad de estructuras de control que son generadas en código Java y poder establecer una comparación contra el diagrama de actividad en cuanto a las estructuras generadas.


Nombre del método

Código original Código generado con ADCODE Diagrama de actividad

Método PrintReceipt ( )

CDC_MIN= 1 CC= 2

CDC_MIN= 1 CC= 2

CDC_MIN= 1 CC= 2


original, en el código generado con ADCODE y en el diagrama de actividad es el mismo. Paso 7. Se realizó con ECLIPSE debido a que los errores de sintaxis son marcados de

inmediato y se puede observar el resultado en la figura 5.30 y 5.31. La advertencia que se observa es debido a que necesita del paquete simulation, que para efectos de ésta prueba no fue anexado a los casos de prueba debido a que no está disponible para descarga. Se observa que el código original y el código generado por ADCODE tienen las mismas advertencias.

Figura 5.30. Comprobación de sintaxis del código original con ECLIPSE del método printReceipt( )

/* Código generado por ADCODE */ import java.io.*; public class ReceiptPrinter{ /*Código del método generado por ADCODE*/ public void printReceipt(Receipt receipt){ Enumeration receiptLines = receipt.getLines();; while( receiptLines.hasMoreElements()){ Simulation.getInstance().printReceiptLine(((String) receiptLines.nextElement())); } } }


- 104 -

Figura 5.31. Comprobación de sintaxis del código generado por ADCODE con ECLIPSE del método printReceipt( )

Paso 8. Se realizaron pruebas de escritorio acerca del diagrama y del código generado, considerando los valores que pertenecen a la clase Receipt que maneja el encabezado del recibo y el balance de la cuenta.

// Heading portion of the receipt headingPortion = new String [4]; headingPortion [1] = atm.getBankName ( ); headingPortion [2] = "ATM #" + atm.getID ( ) + " " + atm.getPlace ( ); headingPortion [3] = "CARD " + card.getNumber ( ) + " TRANS #" + transaction.getSerialNumber(); // Balances portion of the receipt balancesPortion = new String[2]; balancesPortion[0] = "TOTAL BAL: " + balances.getTotal(); balancesPortion[1] = "AVAILABLE: " + balances.getAvailable(); Se obtuvo un recibo con los siguientes datos:

20 de agosto de 2007 Banco CENIDET ATM 2 Cuernavca CARD 2 TRANS 0001 TOTAL BAL: $20.00 AVAILABLE: $10.00

ADCODE LIS RI 00 Generación de código a partir de diagramas de actividad UML

- 105 -

5.5. Reporte de incidentes de prueba (RI) Se encontró que es necesario modificar la métrica para código fuente para que reconozca las estructuras case.

En el reporte de resumen de prueba se observa una gráfica comparativa de los números obtenidos debido al cálculo de la complicad ciclomática.

La herramienta ECLIPSE permite identificar errores de sintaxis al momento, es por ello

que se utilizó esta herramienta para la revisión de sintaxis del código generado con ADCODE. En el código del cajero automático [BJO04] no se encuentra disponible para descarga el

código del paquete simulation. Sin embargo se creó un paquete y una clase con esas descripciones para sustituir al original. También fueron creados métodos main para probar los dos primeros casos de prueba.


- 106 -

5.6. Reportes de resumen de prueba (RR) En el modelado del método nextElement( ) la clase Receipt se encontró una diferencia en la medida de la complejidad ciclomática, debido a que la métrica no está adaptada para funcionar con las estructuras case. Sin embargo en modelado de las estructuras case puede realizarse con múltiples if anidados. Que si son soportados por la métrica de código fuente.

Es así que se obtuvo sólo un caso de 11 que representa el 9% del total, donde la métrica del código original fue diferente a la del diagrama y a la del código generado, como se puede observar en la figura 5.32.

0

1

2

3

4

5

6

CP1a CP1b CP2 CP3a CP3b CP3c CP4 CP5a CP5b CP5c

Código OriginalDiagrama de actividadCódigo ADCODE

Figura 5.32. Valores obtenidos de la complejidad ciclomática.

La sintaxis del código generado fue comprobada con la herramienta ECLPSE. La lógica fue comprobada mediante pruebas de escritorio realizadas sobre el diagrama de

actividad modelado y sobre el código generado de manera automática por ADCODE.

ADCODE LIS RR 00


- 107 -

5.7 Conclusiones del capítulo En el caso de prueba CP1 el tipo de estructuras de control que se modeló es de tipo secuencial. Lo que significa que no tiene condicionales que aumenten el número de la complejidad ciclomática por lo tanto la prueba resultó exitosa porque comprobó dicho valor. El caso de prueba CP2 tiene característica de condicionales anidadas en el modelado y su representación a código fue exitosa. El CP3 tuvo resultados similares al CP1 debido a que tienen características similares. El CP4 contenía estructuras de secuenciación, repetición y selección con valores de retorno en el símbolo final. La representación de estas estructuras en código fue correcta. Por último el CP5 con estructuras de repetición WHILE no tuvo contratiempos en la generación de código y se logró la transformación de ésta estructura a código fuente en Java.

Del total de las pruebas se obtuvo solo una prueba (CP4) donde los números que corresponden a la complejidad ciclomática no coincidieron debido a que la métrica para código fuente no mide los condicionales case. La igualdad de los números no significa que el código generado haga lo mismo que el código original ya que la métrica de la complejidad ciclomática permite estimar las estructuras condicionales que son la base de las estructuras de control no la lógica del programa. En las pruebas se observó que la métrica para código fuente no consideró la complejidad para la estructura Switch_Case pero no se ve afectada la métrica para diagramas de actividad porque se puede modelar el CASE con estructuras condicionales múltiples y anidadas. A eso se debe la diferencia en la gráfica de los valores obtenidos de la complejidad ciclomática. Las pruebas de escritorio realizadas en el paso ocho, permitieron demostrar que la lógica ejecutada en el diagrama de actividad es la misma que la realizada en el código fuente.

Las pruebas realizadas nos permiten comprobar el correcto funcionamiento del procedimiento de transformación de código. El código generado tiene la característica de que cada diagrama de actividad pertenece a un método de una clase, para lo cual no se tomaron en cuenta los atributos de las clases. Sólo las variables definidas dentro del método.


- 108 -

Hoja en Blanco


- 109 -

CAPÍTULO 6 En este capítulo se describirán los siguientes aspectos: 6.1 Introducción 6.2 Conclusiones 6.3 Trabajos Futuros

Resultados y conclusiones

Capítulo 6. Resultados y conclusiones

- 110 -

Capítulo 6. Resultados

6.1. Introducción En éste capítulo se describen las conclusiones obtenidas a partir del trabajo de investigación. Primero se resuelve la pregunta de investigación planteada en el capítulo 2, después se describen las conclusiones obtenidas a lo largo de la tesis. Además se incluyó un apartado de trabajos futuros que podrían realizarse.

6.2 Conclusiones Resolviendo la pregunta de investigación planteada en el capítulo 2.

¿Es posible generar código de las estructuras básicas de manera automática a partir de los diagramas de actividad de UML? La respuesta está en que para lograrlo se deben seleccionar los elementos visuales del diagrama que se deseen modelar, establecer reglas de conexión entre ellos basados en la especificación UML y en las regiones de expansión, definir las etiquetas y mensajes dentro de los elementos visuales del diagrama de actividad (código fuente, OCL o lenguaje natural) y establecer reglas de mapeo según el flujo de control y el lenguaje que se desee generar. Pero la forma de lograrlo es establecer reglas de mapeo del código que se desea generar (puede ser una gramática visual) y definir el contenido que tendrán los elementos gráficos (si será en lenguaje natural o código fuente).

Las conclusiones obtenidas son las siguientes

• Es posible establecer métricas para la comparación de las estructuras de control y los Diagramas de Actividad de acuerdo a lo visto en el capítulo 2.

• Para verificar que la transformación que se realizó de diagramas de actividad a código

fuente fue correcta se realizaron pruebas de escritorio para analizar la lógica del diseño y del código fuente, además se aplicó la métrica de complejidad ciclomática en diagramas de actividad y código fuente para medir la cantidad de estructuras de control en ambos.

• Identificando las estructuras de control dentro del diagrama de actividad se puede generar

código de lenguajes orientados a objetos además de Java. La gramática visual definida en 3.5 permite modelar las estructuras de control, el contenido y las etiquetas del diagrama de actividad son las que definen el lenguaje generado. El símbolo inicial es el encargado de crear un archivo con extensión .java, las propiedades de éste símbolo permitirían crear archivos de extensión .cpp o .h.


- 111 -

• Los diagramas de actividad deben contener información adicional que permita interpretar la semántica de los diagramas de actividad en cuanto a estructuras de control se refiere.

• Se formalizaron los diagramas de actividad que modelan las estructuras básicas de control

mediante la gramática visual relacional, además la gramática permitió realizar una transformación a código basada en las producciones de la gramática.

• Las transiciones de los diagramas de actividad permitieron generar una tabla de

transiciones con las propiedades de las estructuras de control y así lograr la transformación a código fuente a partir de las transiciones del diagrama de actividad.

• La herramienta fue un medio para automatizar el procedimiento de generación de código

y realizar pruebas acerca de la transformación más rápidamente.

6.2.1. Beneficios Obtenidos Los beneficios obtenidos del presente trabajo fueron:

1. Se han formalizado los diagramas de actividad con una gramática visual. 2. La gramática visual de los diagramas de actividad permite representar las estructuras básicas de secuenciación, repetición y selección en código Java. 3. Se obtuvo una forma de comparar el código fuente de las estructuras básicas de secuenciación, repetición y selección contra el diagrama de actividad que no se había establecido en los trabajos de generación de código a partir de diagramas (ver tabla 1.1).

6.2.2. Limitaciones Las limitaciones de ADCODE son:

1. No se implementó consistencia con los diagramas de clases. 2. No se verifica la semántica de los diagramas de actividad ni la lógica del código. 3. Las transiciones sólo siguen trayectorias en línea recta. 4. Los diagramas de actividad no contienen diagramas de actividad anidados. 5. La métrica para código fuente no considera la estructura case.

Capítulo 6. Resultados y conclusiones

- 112 -

6.3. Trabajos Futuros Los trabajos futuros acerca de la generación de código a partir de diagramas de actividad son los siguientes:

1. Actualizar la gramática visual relacional de acuerdo a los cambios que se generen para versiones posteriores de UML. 2. Implementar consistencia con los diagramas de clases. Verificando el cambio del nombre de la clase, métodos o atributos. 3. Generar código en otros lenguajes como C++ o C# mediante la generación de un documento xml que contenga una especificación de las estructuras de control que mediante una hoja de transformación permita generar diferentes lenguajes de programación. 4. Implementar la métrica de complejidad ciclomática para la estructura case. 5. El diagramador puede extender su funcionalidad al generar el XMI del diagrama de actividad y el DTD, lo que permitiría hacer portable el diagrama realizado en ADCODE.


- 113 -

Anexo A

Reporte de diseño de ADCODE

Anexo A. Reporte del diseño de ADCODE

- 114 -

Anexo A. Reporte de diseño de ADCODE.

A.1. Diagramas de Caso de Uso Extendiendo el diagrama de la figura 4.2. En la figura A.1 se observa el modelado visual de los elementos gráficos.

Permitir crear el estado inicial

Crear el estado final

Crear el estado condicional

Crear el estado mergeValidar Conexiones

Permitir creación de notas en el diagrama

Modelar visualmente el diagrama de actividades

<<extend>><<include>>

<<include>>

<<include>>

<<include>><<include>>

Figura A.1. Caso de Uso de modelar visualmente con ADCODE

La validación de conexiones es necesaria para la generación de código y para la creación de transiciones. La figura A.2 muestra éste Caso de Uso.

El flujo se refiere al flujo de control

Verificar que simbolo inicial tenga solo flujo de salida

Verificar que el simbolo final tenga solo flujo de entradaValidar Conexiones

Verificar que los elementos actividad, condicional y mer...

<<include>>

<<include>>

<<include>>

Figura A.2. Caso de Uso Validar conexiones.


- 115 -

El modelado de los objetos debe permitir cambiar las propiedades de los mismos. La figura A.3 muestra el Caso de Uso para esta tarea.

Modelar visualmente Modificar propiedades del diagrama con cuadros de dialogo

<<include>>

Figura A.3. Cambiar propiedades de los elementos gráficos.

La generación de código a partir de diagramas requiere de validar que los elementos

gráficos del diagrama de actividad no estén aislados. El diseñador puede generar código a partir de un diagrama existente. Ver figura A.4.

Diseñador

Genera código

Figura A.4. Generación de código a partir de Diagramas de Actividad

Para medir la correspondencia del código generado y del diagrama modelado se realizó módulo que permite medir la complejidad ciclomática en código Java y la complejidad ciclomática del diagrama de Actividad actual. La figura A.5 muestra el Caso de Uso respectivo.

Metrica para Código Java

Metrica de complejidad ciclomática

Métrica para diagramas de actividad

<<include>>

<<include>>

Figura A.5. Métrica de complejidad ciclomática

A.2. Diagrama de paquetes La figura A.6 muestra el diagrama de paquetes para ADCODE.

Figura A.6. Diagrama de paquetes

Interfaz

Diagrama de Activ idad

Generar Código


- 116 -

A.3. Diagrama de clases La figura A.7 muestra el diagrama de clases para el Diagrama de Actividad. En el se puede observar el patrón Strategy en los elementos gráficos del diagrama mediante las clases CEstadosEstrategia y CRelacionesEstrategia.

CApuntadorDACDblClickDA

CGrafico(CIterator< CGrafico >)

CGrafico

CListIterator

CAsocAdjusterDA

CEstadosEstrategiaDACDiagramaDA

0..11

+m_diagrama

CRelacionesEstrategiaDA

CSelectorDA

0..1

1

+m_clase0..1

1

+m_diagrama

0..1

1

+m_relacion0..1

1

0..1

1

0..1

1

0..1

1

CADCODEDoc

CVisitorDA

0..1

1

+m_docDA 0..1

1

Figura A.7. Diagrama de clases de el diagramador de ADCODE

El diagrama está contraído por elementos figuras y relaciones. Las figuras son manipuladas y creadas mediante la clase CEstadosEstrategiaDA y las relaciones por CRelacionesEstrategiaDA. El diagrama es almacenado en un documento representado por la clase CADCODEDoc. Y los eventos del ratón son manejados en el documento. El botón derecho permite seleccionar una imagen para su movimiento o dibujar una figura.

La figura A.8 muestra el diagrama de clases para el generador de código de ADCODE

donde se observa que el diagrama debe tener cierta validación antes de generar el código. Las conexiones de los elementos gráficos son validadas mediante la clase CValidar la cual

utiliza una copia del diagrama de actividad dibujado. CGenerador es la clase encargada de la generación de código, utiliza a CListaTransición para procesar las transiciones entre los elementos del diagrama de actividad. La clase CListaOrigenes contiene los valores de retorno para la estructura de control IF_ELSE debido a que el flujo de control abierto por el if_else debe ser cerrado y debe existir una posición en las transiciones a donde retornar.


- 117 -

CListaTransicion

CListaOrigenes

CLista

CGeneradorCDA

1

1


1

1

-objLOrigen1

1

+objCadenasPendientes

CDiagramaDA

0..1

1-diagramaLocal

CValidar0..1

1

-diagramaLocal

1

1

1

1

1

1

0..1

1

0..1

1

Figura A.8. Diagrama de clases para el generador de código

La figura A.9. Muestra el diagrama de clases para el generador de código en un nivel más detallado.

CListaTransicion

+ actual: CNodoTransicion*+ aux: CNodoTransicion*+ final: CNodoTransicion*+ inicio: CNodoTransicion*- n: int

+ Agregar(int, int, int, int, int, int, int, int, int, int) : void+ BorraNodoActual(int) : bool+ BorraNodoActual(CNodoTransicion*&) : bool+ CListaTransicion(void)+ ~CListaTransicion(void)+ EstaVacia() : bool+ GetFinal() : CNodoTransicion*+ GetInicio() : CNodoTransicion*+ GetN() : int+ NodoActual(int) : CNodoTransicion *+ ObtenerDestino(int) : CNodoTransicion *+ ObtenerDestino(int, int) : CNodoTransicion *+ ObtenerNodoCElse(int) : CNodoTransicion *+ ObtenerOrigen(int) : CNodoTransicion *+ SetFinal(CNodoTransicion*) : void+ SetInicio(CNodoTransicion*) : void+ SetN() : void+ Siguiente(CNodoTransicion*&) : void+ TipoNodo(int) : CNodoTransicion *

CDocumentCADCODEDoc

CGraficoCDiagramaDA

+ m_lista: CTypedPtrList < CObList, CGrafico * >

+ AcceptVisitors(CVisitor&) : void+ Add(CGrafico*) : void+ CDiagramaDA()+ ~CDiagramaDA()+ Clone() : CGrafico* {query}+ Dibujar(CDC*) : void+ Elements() : CIterator < CGrafico >*+ GetEstadoDA(CPoint) : CEstadosEstrategiaDA*+ GetEstadoDA(int) : CEstadosEstrategiaDA*+ GetEstadoDA(CString) : CEstadosEstrategiaDA *+ getListaFiguras() : CTypedPtrList<CObList,CGrafico*>&+ Intersects(CPoint) : bool {query}+ Remove(CGrafico*) : void+ Serialize(CArchive&) : void

CGeneradorCDA

+ archivoError: bool+ ArchivoJava: CStdioFile+ cNombreArchJava: CString- diagramaLocal: CDiagramaDA*- objLOrigen: CListaOrigenes- objTablaTransiciones: CListaTransicion+ profundidadTab: int

+ CGeneradorCDA(CDiagramaDA*)+ CGeneradorCDA()+ ~CGeneradorCDA(void)+ eliminarTansicionVaciaD_W(int) : CNodoTransicion *+ eliminarTansicionVaciaWyF() : bool+ existeTransicion(int, int, int, int) : bool+ existeTWhile(int) : bool+ existeTWhileM(int) : bool+ GeneraCodigo() : bool+ getTransicionO(int) : int+ objetosAislados() : bool+ ObtenerNodoDiagrama(int) : CGrafico *+ setDiagramaLocal(CDiagramaDA*) : void+ setNombreArtchivo(CString) : void+ simboloActividad(CGrafico*) : void+ simboloBifurcacion(CGrafico*, CNodoTransicion*) : void+ simboloCondicional(CGrafico*, CNodoTransicion*) : int+ simboloFinal(CGrafico*) : void+ simboloInicial(CGrafico*) : bool+ simboloMerge(CGrafico*, CNodoTransicion*) : int+ tablaTransiciones() : void+ tabuladores() : void+ tipoElemento(int) : int


-diagramaLocal

+m_diagrama

Figura A9. Diagrama de clases del generador de código más detallado.


- 118 -

A.4. Diagramas de estados

A.4.1. Diagrama de estados de Elemento gráfico del diagrama La figura A.10 muestra el diagrama de estados para los elementos gráficos, los cuales se pueden crear, modificar y guardar en el diagrama.

Creadonuevo diagrama(); Modificado

Guardado

modificar elementos visuales();

seleccionar guardar diagrama();diagrama borrado();

diagrama borrado();

seleccionar guardar();

diagrama borrado();

Figura A.10. Diagrama de Estados de Elemento gráfico

A.5. Diagramas de actividad

A.5.1. Diagrama de actividad de elemento gráfico La figura A.11 muestra el diagrama de actividad para los elementos gráficos. Si es una transición debe seleccionar el origen y el destino. Si es otro elemento gráfico debe ajustar las propiedades mediante un cuadro de dialogo.

Seleccionar un elemento gráfico en menú

Dibujar

cierto

Ajustar propiedades

Elemento<>relación Seleccionar origen

Seleccionar destino

Dibujar flecha

falso

Figura A.11. Diagrama de actividad para los elementos gráficos


- 119 -

A.5.2. Diagrama de actividad para generar código En la generación de código es necesario tener un diagrama previamente elaborado. Y debe estar abierto al momento de seleccionar la opción de generación. Como lo muestra la figura A12.

Seleccionar generación de código

Mensaje:"Necesita crear un diagrama de actividad"

falso

Existe diagrama actividad

Seleccionar ubicación

cierto

Generar código

Figura A.12 Diagrama para generar código desde el sistema ADCODE.


- 120 -

Hoja en Blanco


121

Anexo B

Utilización de herramienta ADCODE

Anexo B. Utilización de la herramienta ADCODE

- 122 -

Anexo B. Utilización de ADCODE

B.1. Creación de diagrama de actividad La figura B.1 muestra el cuadro de dialogo con las propiedades del símbolo inicial. El nombre de la clase sirve para crear el archivo con código Java. Si el dato no es especificado el código no es generado.

Figura B.1. Propiedades del símbolo inicial.

La figura B.2 muestra el cuadro de dialogo para definir las propiedades del símbolo final. Si no se define un valor de retorno, la palabra return no es mapeada hacia el código generado.

Figura B.2. Propiedades del símbolo final

Para la creación de transiciones entre los objetos es necesario seleccionar el símbolo transición de la barra de herramientas gráfica. Después seleccionar los elementos gráficos origen y destino de la transición. Y en cuadro de propiedades (ver figura B3) de la transición seleccionar el tipo de etiqueta de la transición.

Figura B.3. Selección del tipo de transición


- 123 -

La figura B4 muestra el resultado de unir el estado inicial con el estado final mediante una transición.

Figura B.4. Utilización del elemento gráfico transición

En la generación de código se tomaron en cuenta las sentencias de lectura y escritura para

la generación de código. Las instrucciones de código libre se dejaron abiertas al usuario del sistema lo que puede provocar errores en la compilación del código. La figura B5 el cuadro de dialogo para configurar las propiedades del símbolo actividad.

Figura B.5. Propiedades del elemento gráfico Actividad

El símbolo condicional sirve para modelar las estructuras de selección y repetición. Las propiedades del símbolo condicional pueden observarse en la figura B6.

Figura B.6. Propiedades configurables del símbolo condicional

Anexo B. Utilización de la herramienta ADCODE

- 124 -

B.2. Eliminación de elementos gráficos del diagrama de actividad Cuando un estado es eliminado también se eliminan todas sus transiciones ver figura B7. En el caso del símbolo condicional se elimina el símbolo merge que fue creado al mismo tiempo que el condicional.

Figura B.7. Eliminar una transición.

B.3. Generación de código.

Si la generación de código ha sido exitosa se mostrará un cuadro de dialogo como el de la figura B.8.

Figura B.8. Mensaje de código generado con éxito

Pueden existir errores en la generación de código. Los factores que ocasionan los errores son: no definir las propiedades en los símbolos gráficos, elementos aislados y lógica sintaxis del diagrama equivocada y cuando suceden ADCODE notifica con mensajes de error. La figura B9 notifica un error de tipo donde las propiedades de los símbolos no están definidas.

Figura B.9. Mensaje de error en la generación del código


- 125 -

Si existe algún elemento aislado es decir que no tenga flujo de entrada o de salida manda un mensaje de error como el de la figura B10.

Figura B.10. Mensaje de símbolo aislado en el diagrama.

Referencias bibliográficas

- 126 -

Hoja en Blanco


- 127 -

Referencias bibliográficas [ALI99] ALI, J. y TANAKA, J. Converting statecharts into Java code. In 5th International Conference on Integrated Design and Process Technology (IDPT'99), Dallas, Texas, June 1999. http://www.iplab.cs.tsukuba.ac.jp/paper/international/ali-idpt99.pdf Consultado el 22 de septiembre del 2006. [ALB07] ALBORES VILLATORO, LUZ ANGELINA. “Definición e implementación de un perfil de UML para la adquisición de requerimientos funcionales centrados en el usuario”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 2007. [ALF06] ALFONZO GARCÍA, JOSÉ ARMANDO. “Aplicación de un proceso de ingeniería inversa a código C++ para obtener diagramas de secuencias”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 2006. [ARL05] ARLOW, JIM. NEUSTADT, ILA. UML 2 and the unified process. 2005. Segunda edición. Editorial Addison Wesley. P. 537 ISBN. 0-321-32127-8 [BJO04] BJORK, RUSSELL C. ATM Simulation. Gordon College. Copyright © 2004. http://www.math-cs.gordon.edu/courses/cs211/ATMExample/ Consultado el 9 de agosto del 2007. [BOH66] BOHM C. Y JACOPINI G. “Flow diagrams, Turing machines, and lenguajes only with two formation rules”. ACM 1966. Vol. 9. Núm. 5. pp. 366-371. [BOO99a] G. BOOCH, J. RUMBAUGH, I. JACOBSON. El Lenguaje Unificado de Modelado, Addison Wesley Iberoamericana, Madrid, 1999. pp. 4-7. [BOO99b] G. BOOCH, J. RUMBAUGH, I. JACOBSON. El Lenguaje Unificado de Modelado, Addison Wesley Iberoamericana, Madrid, 1999. pp. 82-83. [BOO99c] G. BOOCH, J. RUMBAUGH, I. JACOBSON. El Lenguaje Unificado de Modelado, Addison Wesley Iberoamericana, Madrid, 1999. pp. 225-239. [CAS03] ROMÁN CASTAÑEDA, JAVIER. “Sistema para el diseño detallado de métodos de clases con UML”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, Marzo de 2003. p. 83. [CAB04] CABRERA SANTIAGO, NUBIA. “Ambiente de modelado y documentación de sistemas de software utilizando diagramas de casos de uso”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, Mayo del 2004. [CAZ04] DANIEL CAZZULINO, MAYO DE 2004, Generación de código en .NET Framework utilizando un esquema XML,


- 128 -

http://www.microsoft.com/spanish/msdn/articulos/archivo/010604/voices/Doc3SPA.asp. Consultado el 2 de abril del 2006. [ENT06] Sparxsystems ENTERPRISE ARCHITECTURE http://www.sparxsystems.com Consultado el 30 de agosto de 2006 [ESH04a] ESHUIS, R. WIERINGA, R. "Tool support for verifying UML activity diagrams," IEEE Trans. on Software Eng., vol. 7, no. 30, 2004. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=29218&arnumber=1318605&count=5&index=1 Consultado en http://spic.kaist.ac.kr/~selab/html/Study/Lab%20Seminar/Tool%20Support%20for%20Verifying%20UML%20Activity%20Diagrams.pdf el 30 de agosto de 2006. [FUJ06] FUJABA Tool Suite. Universidad de Paderborn. http://wwwcs.uni-paderborn.de/cs/fujaba/ Consultado el 15 de diciembre de 2006. [GAL05] GALLINA, BARBARA. GUELFI NICOLAS. MAMMAR, AMEL. Structuring Business Nested Processes Using UML 2.0 Activity Diagrams and Translating into XPDL. http://se2c.uni.lu/tiki/se2c-bib_download.php?id=1962 Consultado el 28 de enero de 2007. [GON04] GONZALES MIRANDA, ALEJANDRO. “Ambiente visual de modelado del estado de objetos de una clase utilizando los diagramas de estados propuestos por UML”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 2004. [HER03] HERNÁNDEZ VELÁSQUEZ, MIGUEL. “Ingeniería inversa de código fuente en C++ para la obtención de su diseño”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 2003. p. 19.

[IEEE98] ANSI/IEEE Standard 829-1998 for Software Test Documentation. IEEE Press, 1998. Este estándar se incluye en la colección Software Engineering Standards publicado por IEEE Press.

[MAI06] MAIER, THOMAS. ZUNDORF, ALBERT. The FUJABA Statechart Synthesis Approach. http://www.doc.ic.ac.uk/~su2/SCESM/papers/Zundorf.pdf. Consultado el 14 de noviembre del 2006. [MAC04] MACIAS MONTOYA, JOSÉ ALONSO. “Ambiente de modelado y diseño de sistemas de software utilizando diagramas de secuencias”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 2004. [MCQ06] MCQUILLAN JACQUELINE A., POWER JAMES F. Some observations on the application of software metrics to UML models. Consultado en http://www.cs.nuim.ie/~jpower/Research/Papers/2006/modelsize06.pdf el 4 de julio del 2007.


- 129 -

[MCQ07] MCQUILLAN JACQUELINE A., POWER JAMES F. On the Application of Software Metrics to UML Models. Models in Software Engineering Springer Lecture Notes in Computer Science, Vol. 4364. Consultado en http://www.minds.nuim.ie/~jmcq/models2007.pdf. [MAR97] MARTINEZ REBOLLAR, ALICIA. “Generador de código para lenguaje C utilizando una notación de diseño detallado”. Tesis de Maestría. Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 1997. [MAR07] SERGIO R. MARTIG, Administración y Gestión de Proyectos de Software. Universidad Nacional del Sur. Argentina. Consultado en http://cs.uns.edu.ar/~srm/agps/Archivos/Clases/Admc07_4.pdf el 4 de julio del 2007. [MOF06] OBJECT MANAGEMENT GROUP (OMG), Meta Object Facility (MOF) Core Specification version 2.0, 01-01-06. http://www.omg.org/technology/documents/formal/MOF_Core.htm. Consultado el 26 de marzo del 2006. [NIA04] NIAZ, I. A. TANAKA, J. Mapping UML Statecharts To Java Code. IASTED International Conference on Software Engineering (SE 2004), Innsbruck, Austria, Febrero 17-19, 2004, pp. 111-116. Consultado en http://www.iplab.cs.tsukuba.ac.jp/paper/international/niaz_se2004.pdf [NUÑ04] NUÑEZ URBINA, ALICIA ANGELICA. “Ingeniería inversa para la obtención de diagramas de clases y diseño detallado basado en diagramas de Warnier para código escrito en Java”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, Mayo del 2004. [OMG06] OBJECT MANAGEMENT GROUP. http://www.omg.org/ Consultado el 14 de marzo de 2006. [PAR00] PARRA RAMIREZ, ISAAC ALBERTO, “Modelado visual orientado a objetos”. Tesis de Maestría. Cuernavaca, Morelos, Centro Nacional de Investigación y Desarrollo Tecnológico, 2000. [POS06] Gentleware. POSEIDON, www.gentleware.com Consultado el 30 de agosto de 2006 [PRE05] PRESSMAN, ROGER S. Software Engineering: A Practitioner's Approach. McGraw-Hill. Sexta Edición. 2005. pp. 388-430. [PRE05a] PRESSMAN, ROGER S. Software engineering: approach. 6th Ed. (New York, USA. McGrawhill, 2005) p. 623. ISBN 0-07-285318 [PRE02b] PRESSMAN, ROGER S. Ingeniería del Software. Un enfoque práctico. Quinta Edición. (Madrid, España. McGrawhill/Interamericana de España, 2002) p. 190. [QUI05] QUINTERO, Juan Bernardo; ANAYA DE PÁEZ, Raquel; MARÍN, Juan Carlos; BILBAO LÓPEZ, Alex. “Un estudio comparativo de herramientas para el modelado con UML”.


- 130 -

Journal: Revista Universidad Eafit Vol: 41 Issue: 137. Consultado en http://www.doaj.org/abstract?id=158610&toc=y el 2 de junio de 2006. [RAT06] IBM. RATIONAL ROSE www.rational.com. Consultado el 30 de agosto de 2006 [REY05] REYNOSO, LUIS. GENERO, MARCELA. PIATTINI, MARIO. MANSO ESPERANZA. Assessing the Impact of Coupling on the Understandability and Modifiability of OCL Expressions within UML/OCL Combined Models Consultado en http://www.giro.infor.uva.es/Publications/2005/RGPM05a/reynoso-genero-manso-OCL-ieee-2005.pdf el 7 de febrero del 2006. [RHA06] ILOGIX. Rhapsody 6.1. www.ilogix.com. Consultado el 14 de marzo de 2006. [ROM03] ROMÁN CASTAÑEDA, Javier. “Sistema para el diseño detallado de métodos de clases con UML”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, Marzo de 2003. p. 83. [RUM96] RUMBAUGH, JAMES. BLAHA, MICHAEL. Modelado y diseño orientado a objetos. Metodología OMT. Páginas 37-41. [SAN06] SANTAOLAYA SALGADO, RENE. Reporte de calidad SIGEFI, enero del 2006. [SMA06] APESOFT. SmartState v4.1 www.SmartStateStudio.com. Consultado el 23 de agosto de 2006. [STO04a] STOERRLE, HARALD. HAUSMANN JAN HENDRIK. “Semantics and Verification of Data Flow in UML 2.0 Activities” http://www.pst.informatik.uni-muenchen.de/personen/stoerrle/V/AD2b-DataFlow.pdf Publicado en 2004. Consultado 30 de agosto de 2006. [STO04b] STOERRLE, HARALD. HAUSMANN JAN HENDRIK. “Towards a Formal Semantics of UML 2.0 Activities” http://www.hwswworld.com/downloads/9_28_05_e/SE2005-Stoerrle-Hausmann-ActivityDiagrams.pdf . Publicado en 2004. Consultado 30 de agosto de 2006. [STO04c] STOERRLE, HARALD. HAUSMANN JAN HENDRIK. Semantics of Structured Nodes in UML 2.0 Activities http://www.pst.informatik.uni-muenchen.de/personen/stoerrle/V/AD4-Expansion.pdf Consultado 30 de agosto de 2006. [TAK06] TAKEMUDA, TSUKASA. TAMAI, TETSU. Rigorous Business Process Modeling Rigorous Business Process Modeling with OCL.OCL for (Meta-)Models in Multiple Application Domains (OCLApps) workshop at Models/UML 2006, Genoa, Italia, Octubre 2006, pp.68-80. Consultado en http://st.inf.tudresden.de/OCLApps2006/topic/acceptedPapers/18_Takemura_BPMwithOCL. [TOG06] Borland. Together www.borland.com


- 131 -

[TRO03] TRONG THANH TRUNG DINH, “Rules for generating code from UML collaboration diagrams and activity diagrams”. Universidad del estado de Colorado. 2003, http://www.cs.colostate.edu/~trungdt/code_generation/Thesis.pdf, Consultado el 3 de abril de 2006. [UML06] Object Management Group (OMG), What_is_uml, http://www.omg.org/gettingstarted/what_is_uml.htm. Consultado el 16 de enero del 2006. [VAL04] VALDEZ BESARES, JOSÉ GUILLERMO. “Ambiente visual para la integración de clases utilizando diagrama de paquetes”. Tesis de Maestría, Cuernavaca, Morelos, México. Centro Nacional de Investigación y Desarrollo Tecnológico, 2004. [UMT06] UML Model transformation tool. https://sourceforge.net/projects/umt-qvt/ Consultado el 23 de Agosto de 2006. [WEN02] WENCES DÍAZ, MARTHA FABIOLA, “Modelo de ingeniería inversa para la obtención de diseño detallado basado en Leviss”. Tesis de Maestría. Cuernavaca, Morelos, Centro Nacional de Investigación y Desarrollo Tecnológico, 2002. [WIT06] MICROGOLD. WithClass http://www.microgold.com/ Consultado el 30 de agosto de 2006 [ZUN01] ZÜNDORF, ALBERT. 2001. http://www.coobra.cs.uni-kassel.de/fileadmin/se/publications/Zuen02.pdf Consultado el 23 de agosto del 2006.

· 2014-04-02 · Transformación de diagramas de actividad a código fuente en Java.....- 37 -...

Documents

Transcript of · 2014-04-02 · Transformación de diagramas de actividad a código fuente en Java.....- 37 -...