universidad del istmocomputacion/tesis/tesisgetsemani.pdfuniversidad del istmo campus tehuantepec...
TRANSCRIPT
UNIVERSIDAD DEL ISTMO Campus Tehuantepec
INGENIERÍA EN COMPUTACIÓN
“SOFTWARE PARA LA ASISTENCIA EN EL APRENDIZAJE DE
ALGORITMOS EMPLEANDO LA HEURÍSTICA DE POLYA”
T E S I S
Para obtener el título de
Ingeniero en Computación
PRESENTA:
Getsemaní Arista López
DIRECTOR DE TESIS:
M. C. J. Jesús Arellano Pimentel
Santo Domingo Tehuantepec, Oaxaca Abril 2012
UNIVERSIDAD DEL ISTMO
Campus Tehuantepec
APROBACIÓN DE TESIS
INGENIERÍA EN COMPUTACIÓN
“SOFTWARE PARA LA ASISTENCIA EN EL APRENDIZAJE DE ALGORITMOS
EMPLEANDO LA HEURÍSTICA DE POLYA”
T E S I S
Para obtener el título de
Ingeniero en Computación
PRESENTA:
Getsemaní Arista López
DIRECTOR DE TESIS:
M. C. J. Jesús Arellano Pimentel
Nombre del Revisor Firma Fecha
M.C. J. Jesús Arellano Pimentel
M.C. Omar Santiago Nieva García
M.C. Daniel Pacheco Bautista
M.S.C. Cynthya García de Jesús
Dr. Miguel Ángel Hernández López
TTTTTTTTzzzzzzzzÜÜÜÜÜÜÜÜttttttttwwwwwwwwxxxxxxxxvvvvvvvv||||||||ÅÅÅÅÅÅÅÅ||||||||xxxxxxxxÇÇÇÇÇÇÇÇààààààààÉÉÉÉÉÉÉÉáááááááá
A Dios por permitirme vivir este momento en compañía de mi familia y amigos.
A mis padres Ignacio Arista Iglesias y Julia López por su amor, paciencia y apoyo incondicional,
los amo con todo mi corazón.
A mis hermanos, cuñados y sobrinos, teniendo a una familia tan unida como ustedes soy muy feliz.
Al mejor amigo que puede existir que de cariño le llamo “Carlangas” te quiero muchísimo.
Al M.C. J. Jesús Arellano Pimentel, por compartir sus conocimientos y por los ánimos que siempre
me inyectaba para seguir adelante.
A la Universidad del Istmo y sus profesores quienes nos forman como profesionistas cada día en
sus aulas.
Al jefe de carrera M.C. Daniel Pacheco Bautista, por su apoyo y accesibilidad.
A los integrantes del grupo de danza “Binni’Zaa” por ser parte de una de mis pasiones.
Y a cada una de las personas que me ha brindado su verdadera amistad. Gracias amigos porque
sin cada uno de ustedes, mi vida no fuera la misma.
RESUMEN
El propósito de este trabajo de tesis es desarrollar una herramienta de software multiplataforma,
aplicando ingeniería de software orientada a objetos y reingeniería de software, a un prototipo
inicial llamado ABEA (Asistente Básico en la Enseñanza de Algoritmos). Además de generar la
documentación de la herramienta resultante llamada “Software para la asistencia en el aprendizaje
de algoritmos” (SAAA), usando el método de Proceso Unificado y diagramas del Lenguaje
Unificado de Modelado. Dando como resultado una herramienta de apoyo didáctico para el
aprendizaje de algoritmos que aplica la heurística de Polya, la cual contribuye a eliminar los
“malos” hábitos de resolución de problemas a prueba y error. Si dicha herramienta se utiliza en
conjunto con una estrategia de aprendizaje, entonces se puede lograr un aprendizaje significativo1
en los estudiantes que toman cursos introductorios de algoritmos y programación, desarrollando una
metodología sólida para la resolución de problemas la cual les permitirá disminuir sustancialmente
las dificultades al momento de aprender y aplicar nuevos paradigmas y lenguajes de programación.
La metodología de desarrollo empleada en la construcción del SAAA consiste principalmente en 5
flujos de trabajo (workflows) del Proceso Unificado llamados: workflow de los requisitos, workflow
del análisis, workflow del diseño, workflow de la implementación y el workflow de pruebas.
Para destacar las ventajas del SAAA con respecto a otras herramientas que también buscan servir
como apoyo didáctico en la enseñanza-aprendizaje de algoritmos, se realiza una serie de
comparaciones de las principales características que el SAAA ofrece, con los software llamados
SICAS, RAPTOR, FreeDFD y ABEA. Finalmente, a manera de conclusión se tiene que el SAAA
aventaja a estas herramientas al implementar características importantes que ayudan al usuario en el
aprendizaje de algoritmos siguiendo una metodología de resolución de problemas. Y aunque el
software no implemente aún algunas características (por ejemplo el soporte de variables de tipo
arreglo), estas forman parte del trabajo futuro de la presente tesis.
1 Aprendizaje permanente que produce nuevos conocimientos con base en la experiencia
i
CONTENIDO
Introducción ..................................................................................................................................... 1
1.1. Motivación ....................................................................................................................... 3 1.2. Planteamiento del Problema............................................................................................. 4 1.3. Estado del Arte................................................................................................................. 6 1.4. Objetivos ........................................................................................................................ 10
1.4.1. Objetivo General .................................................................................................... 10 1.4.2. Objetivos Específicos............................................................................................. 10
1.5. Justificación ................................................................................................................... 11 1.6. Organización del Documento......................................................................................... 13
Marco Teórico................................................................................................................................ 14
2.1. Introducción ................................................................................................................... 15 2.2. Ingeniería de Software ................................................................................................... 15
2.2.1. El Proceso Unificado (UP)..................................................................................... 17 2.2.2. UML....................................................................................................................... 19
2.3. Reingeniería de Software ............................................................................................... 20 2.4. Compiladores ................................................................................................................. 23
2.4.1. Fases de Compilación ............................................................................................ 24 2.4.2. Gramáticas Libres de Contexto.............................................................................. 27 2.4.3. Análisis por Descenso Recursivo........................................................................... 28 2.4.4. Intérpretes............................................................................................................... 30
2.5. Software Educativo ........................................................................................................ 32 2.5.1. Esquema de Aprendizaje........................................................................................ 32
2.6. Heurística de Polya ........................................................................................................ 33 Desarrollo de la Herramienta de Software ..................................................................................... 35
3.1. Introducción ................................................................................................................... 37 3.1.1. Metodología de Desarrollo..................................................................................... 38
3.2. Workflow de los Requisitos ........................................................................................... 39 3.2.1. Esquema General de la Herramienta...................................................................... 39
3.2.2. Funcionalidades de la Herramienta........................................................................ 41
3.2.3. Restricciones .......................................................................................................... 48 3.2.4. Características de los Usuarios............................................................................... 49
3.3. Workflow del Análisis ................................................................................................... 50 3.3.1. Diagrama de Clases................................................................................................ 50 3.3.2. Diagramas de Estado.............................................................................................. 58 3.3.3. Diagramas de Secuencia ........................................................................................ 59
3.4. Workflow del Diseño ..................................................................................................... 65
ii
3.4.1. Diagrama de Paquetes ............................................................................................65 3.5. Workflow de la Implementación....................................................................................69
3.5.1. Plataforma de Implementación...............................................................................69 3.5.2. Reutilización de Código .........................................................................................72 3.5.3. Diagrama de Despliegue.........................................................................................78
3.6. Workflow de Pruebas .....................................................................................................79 3.6.1. Prueba de Utilidad ..................................................................................................79 3.6.2. Prueba de Fiabilidad...............................................................................................80 3.6.3. Prueba de Solidez o Robustez ................................................................................80 3.6.4. Prueba de Desempeño ............................................................................................81 3.6.5. Prueba de Corrección .............................................................................................81
Resultados ......................................................................................................................................83
4.1. Resultados Comparativos con Software Similares.........................................................85
4.2. Resultados Comparativos con la Versión Anterior ........................................................87
4.3. Caso de Ejemplo.............................................................................................................88 4.3.1. Etapa Analizar ........................................................................................................88 4.3.2. Etapa Planear..........................................................................................................91 4.3.3. Etapa Diseñar .........................................................................................................93 4.3.4. Etapa Probar ...........................................................................................................96
Conclusiones y Trabajos Futuros ...................................................................................................99 5.1. Conclusiones ................................................................................................................101 5.2. Trabajo Futuro..............................................................................................................102
Bibliografía.....................................................................................¡Error! Marcador no definido.
Contenido Apéndices ...................................................................................................................107
A. Casos de Uso ................................................................................................................109 B. Diagramas de Clases ....................................................................................................127 C. Manual de Usuario .......................................................................................................127
iii
ÍNDICE DE FIGURAS Figura 1 Interfaz de la herramienta SICAS......................................................................................... 7 Figura 2 Interfaz de la herramienta RAPTOR .................................................................................... 7 Figura 3 Interfaz de la herramienta freeDFD...................................................................................... 8 Figura 4 Interfaz de la herramienta ABEA ......................................................................................... 9 Figura 5 Fases del proceso unificado................................................................................................ 17
Figura 6 Modelo de proceso de reingeniería de software ................................................................. 21 Figura 7 Esquema general de un compilador.................................................................................... 23 Figura 8 Fases de un compilador ...................................................................................................... 24
Figura 9 Intérprete avanzado............................................................................................................. 31
Figura 10 Esquema de aprendizaje ................................................................................................... 33
Figura 11 Etapas de la heurística de Polya........................................................................................ 34 Figura 12 Esquema general para el desarrollo de la herramienta de software.................................. 38 Figura 13 Concordancia entre la heurística de Polya y la herramienta de software.......................... 39 Figura 14 Herramienta desde la perspectiva de compiladores e intérpretes ..................................... 40 Figura 15 Diagrama de casos de uso de la herramienta .................................................................... 41 Figura 16 Estructura de un diagrama de clases................................................................................. 50 Figura 17 Diagrama de clases para ClaseAnalisis ............................................................................ 51 Figura 18 Diagrama de clases para ClasePlaneacion........................................................................ 52 Figura 19 Diagrama de clases para DiagramaFlujo .......................................................................... 53 Figura 20 Diagrama de clases para ClaseEjecutar ............................................................................ 54 Figura 21 Diagrama de clases UML para el sistema......................................................................... 57 Figura 22 Diagrama de estados del sistema ...................................................................................... 58 Figura 23 Diagrama de estados en una sesión normal utilizando la herramienta ............................. 59
Figura 24 Diagrama de secuencia para la etapa Analizar ................................................................. 60 Figura 25 Diagrama de secuencia para la etapa Planear ................................................................... 60 Figura 26 Diagrama de secuencia para construir un diagrama de flujo en la fase Diseñar............... 61
Figura 27 Diagrama de secuencia para compilar un diagrama de flujo en la fase Diseñar............... 62
Figura 28 Diagrama de secuencia para un escenario de ejecución (Hola mundo) en la etapa Probar........................................................................................................................................................... 64
Figura 29 Diagrama del PaquetePrincipal......................................................................................... 66 Figura 30 Diagrama del PaqueteAnalizar ......................................................................................... 66 Figura 31 Diagrama del PaquetePlaneacion ..................................................................................... 67 Figura 32 Diagrama del PaqueteDiagramaFlujo............................................................................... 67 Figura 33 Diagrama del PaqueteCompilar........................................................................................ 68 Figura 34 Diagrama del PaqueteEjecutar.......................................................................................... 68 Figura 35 Diagrama del PaqueteCDAuxiliares................................................................................. 69 Figura 36 NetBeans 6.9.1.................................................................................................................. 71
Figura 37 Diagrama de despliegue.................................................................................................... 79
Figura 39 Pestaña Analizar para el caso ejemplo (con información)................................................ 90
iv
Figura 40 Pestaña Planear para el caso ejemplo (sin información)................................................... 91 Figura 41 Pestaña Planear para el caso ejemplo (con información).................................................. 92 Figura 42 Pestaña Diseñar................................................................................................................. 93
Figura 43 Diagrama de flujo que calcula la hipotenusa .................................................................... 94 Figura 44 Pestaña Probar................................................................................................................... 96
Figura 45 Ejecución terminada del diagrama de flujo....................................................................... 97 Figura 46 Cuadro de diálogo estándar Guardar............................................................................... 111 Figura 47 Cuadro de diálogo estándar Abrir ................................................................................... 111 Figura 48 Diagrama de clases para ClaseAnalisis........................................................................... 127 Figura 49 Diagrama de clases para ClasePlaneacion ...................................................................... 127 Figura 50 Diagrama de clases para DiagramaFlujo ........................................................................ 128 Figura 51 Diagrama de clases para ClaseEjecutar .......................................................................... 129
v
ÍNDICE DE TABLAS
Tabla 1 Caso de uso Analizar............................................................................................................ 43
Tabla 2 Caso de uso Planear ............................................................................................................. 44
Tabla 3 Caso de uso Diseñar............................................................................................................. 45
Tabla 4 Caso de uso Compilar .......................................................................................................... 46
Tabla 5 Caso de uso Probar............................................................................................................... 47
Tabla 6 Descripción breve de las clases que componen el software................................................. 54
Tabla 7 Comparativa con otras herramientas similares .................................................................... 85
Tabla 8 Mejoras del software actual respecto a la herramienta ABEA............................................. 87
Tabla 9 Tabla para la lista de elementos ........................................................................................... 91
Tabla 10 Propiedades de la Lista de asignación de identificadores .................................................. 92
CCAAPPII TTUULL OO 11
INTRODUCCIÓN
1.1. Motivación
1.2. Planteamiento del problema
1.3. Estado del arte
1.4. Objetivos
1.5. Justificación
1.6. Organización del documento
3
1.1. MOTIVACIÓN
En la actualidad los alumnos de nivel superior que cursan carreras de ingeniería y especialmente
aquellos inscritos en las carreras afines a las ciencias computacionales, necesitan aprender a
programar de forma correcta soluciones algorítmicas a problemas computables utilizando diferentes
paradigmas con diversos lenguajes y herramientas de programación. La forma habitual de enseñar a
programar es forzando al estudiante a resolver un gran número de ejercicios y problemas con el
método de codificar, probar y corregir hasta lograr que el programa arroje los resultados correctos.
Se ha dejado de lado la importancia de entender a cabalidad un problema para concebir un
algoritmo de solución.
Actualmente existen diversas herramientas de software que sirven como apoyo didáctico en la
enseñanza de algoritmos, sin embargo, la gran mayoría se enfoca en las fases de diseño y prueba de
la solución algorítmica, solo unas pocas herramientas dan soporte a las fases de análisis del
problema y planteamiento de la estrategia de solución. Al no tener soporte las fases de análisis y
planteamiento, queda inconcluso el apoyo que debe tener el estudiante para que ejercite y desarrolle
la capacidad de resolver problemas, ya que no se le orienta al usuario para que primero extraiga
toda la información posible del enunciado inicial del problema y con base en esto, planee una
solución.
El presente trabajo de tesis documenta la construcción y prueba de una nueva herramienta de
software que servirá como asistente en el aprendizaje de algoritmos. Esta herramienta tomará como
base un software llamado ABEA2, el cuál será estudiado para comprender su arquitectura y conocer
sus principales ventajas así como sus carencias. Los resultados del estudio permitirán definir el
conjunto de nuevas características a implementar a fin de producir la versión ampliada y mejorada
del software. Es importante mencionar que el proceso de desarrollo utilizará técnicas de ingeniería y
reingeniería de software para la construcción de la nueva herramienta a partir de ABEA.
A continuación se plantea el problema que existe debido a la carencia de este tipo de herramientas y
la importancia de contar ellas.
2 Asistente Básico en la Enseñanza de Algoritmos
4
1.2. PLANTEAMIENTO DEL PROBLEMA
La mayoría de las herramientas de apoyo didáctico en la enseñanza de algoritmos asumen que el
estudiante sabe cómo analizar un problema y esbozar una solución en instrucciones algorítmicas.
A partir de la aseveración anterior consideramos que es necesario contar con herramientas de
software para dar soporte completo a todas las fases del desarrollo de una solución algorítmica. Con
base en la heurística de Polya (Polya, 2005) tales fases son: análisis del problema, planteamiento de
la solución, diseño formal del algoritmo, y la prueba del algoritmo.
Una herramienta de este tipo debería encajar perfectamente en un esquema de aprendizaje que
involucre: recursos, actividades y apoyos. En este sentido se busca que la herramienta sea el
principal apoyo que brinde la asistencia necesaria para lograr que el estudiante adquiera, aplique y
ejercite la habilidad de desarrollar soluciones algorítmicas.
Actualmente existe un prototipo inicial (Arellano Pimentel & Nieva García, 2010) que encaja con el
esquema de aprendizaje que se propone y también se basa en la heurística de Polya. Sin embargo a
través de pruebas exhaustivas del prototipo inicial realizadas por el autor del presente documento,
se detectó que dicho prototipo aún carece de algunas características deseables tales como:
• Traducción del diseño formal del algoritmo dado en diagrama de flujo a pseudocódigo y
código fuente en C.
• Visualizar mediante el uso de distintos colores las diversas estructuras de control en un
diagrama de flujo.
• Empleo de funciones básicas de librería en las operaciones de cálculo. Funciones tales
como: raíz cuadrada, seno, coseno, etc.
• Mayor portabilidad entre distintos sistemas operativos.
• Asignación de valores iniciales a los identificadores en la pestaña Planteamiento.
• Adición de las condiciones en la traza de la corrida de escritorio del diagrama de flujo en la
pestaña Prueba.
Además las pruebas exhaustivas realizadas también permitieron detectar algunos errores en el
prototipo inicial, entre estos están:
5
• La gramática de los elementos de Entrada/Salida permite una coma al final de una
secuencia de identificadores, lo cual es incorrecto.
• En la pestaña Prueba, al finalizar la ejecución de un diagrama de flujo, en ocasiones el
cuadro de diálogo que notifica el final de la ejecución queda en segundo plano, aparentando
un bloqueo de la aplicación.
• En la pestaña Diseño, la herramienta permite solo la acción de cortar estructuras
secuenciales, y no permite la secuencia seleccionar-copiar-pegar sobre cualquier tipo de
estructura.
• No está activa la opción de ayuda para el usuario en todas las etapas.
• En la pestaña Planteamiento, el nombre de los elementos de la lista de elementos no se
actualiza automáticamente en la lista de asignación de identificadores.
• Como fue desarrollado originalmente para el sistema operativo Linux, la conversión para
Windows genera inconsistencias de colores en la corrida de escritorio.
• La herramienta solo implementa la opción Guardar como y no con la opción Guardar.
Además al cerrar la aplicación no pregunta al usuario si desea guardar la solución actual.
• Al notificar el resultado de la compilación, muestra un cuadro de diálogo por cada error
generado provocando una cantidad excesiva de notificaciones.
• En ocasiones, en la pestaña Diseño se genera un elemento inicializar vacío (sin variables) al
generar el diagrama de flujo por omisión, lo cual es incorrecto.
• Se cuenta con barras de herramientas que incluyen botones cuya funcionalidad no está
activa o implementada.
El presente proyecto plantea resolver el problema de reconstruir el prototipo inicial antes
mencionado corrigiendo los errores encontrados y adicionándole la lista de características de las que
aún carece. Por lo que será necesario aplicar el Proceso Unificado (UP) (Schach, 2005) para el
desarrollo de software así como técnicas de reingeniería de software (Pressman, 2002) afín de
generar una versión mejorada del prototipo inicial completamente documentada.
6
Cabe mencionar que los autores del prototipo inicial han señalado, de su propia voz, que la
herramienta fue desarrollada bajo el modelo de construcción de prototipos y el paradigma
estructurado con escasa documentación en el código fuente.
1.3. ESTADO DEL ARTE
Existen varias herramientas de software para ayudar a estudiantes en el proceso de enseñanza-
aprendizaje de habilidades de programación. Estas herramientas pueden clasificarse en narrativas,
basadas en representaciones y de programación visual.
Una de estas herramientas es la llamada SICAS3 (Marcelino & Gomes, 2004), la cual permite
observar qué sucede si el orden de las acciones cambia o qué resultados se puede obtener, haciendo
variaciones en el guión de la historia. Otra característica importante de SICAS (ver Figura 1) es que
posee un modo estudiante y un modo profesor, permitiendo al modo profesor realizar una serie de
problemas con soluciones que servirán a los alumnos para comparar sus resultados. Los tipos de
datos que soporta esta herramienta son: numéricos, cadenas, arreglos de cadenas y arreglo
numéricos. Sin embargo, no cuenta con soporte para las fases del análisis y planteamiento del
problema.
Otra herramienta importante es el software llamado RAPTOR4 (Charlise, Willson, & al., 2004) (ver
Figura 2), el cual muestra cómo van cambiando las variables conforme va ejecutándose el diagrama
de flujo. Algunas de las características importantes son: corre bajo el Framework .NET, es de
licencia gratuita, soporta las estructuras secuenciales, cíclicas (solo hacer mientras), procedimientos,
llamadas, asignaciones, entradas y salidas. Se encuentra en un continuo proceso de actualización y
desarrollo, la última versión del RAPTOR es el 4.0.2 realizada en el año 2010. Cuenta con una
página web (RAPTOR. Flowchar interpreter) donde además de poder consultar la última versión del
raptor, también es posible descargar algunos manuales.
3 SICAS: Interactive system for algorithm development and simulation.
4 RAPTOR: Rapid Algorithmic Prototyping Tool for Ordered Reasoning.
7
Figura 1 Interfaz de la herramienta SICAS
Figura 2 Interfaz de la herramienta RAPTOR
8
La Figura 3 presenta otra herramienta similar pero con mayor popularidad en el idioma español
llamado DFD5 (Cardenas Valera, Castillo Izquierdo, & Daza Castillo, 1998), las últimas
actualizaciones de esta herramienta se conocen como freeDFD y están disponibles en línea (freedfd,
2008). DFD es un software libre diseñado para construir y analizar algoritmos expresados en
diagramas de flujo. Además permite mediante un entorno interactivo el depurado de los algoritmos,
facilitando así la localización de los errores de ejecución y lógicos más habituales. La interfaz
gráfica de DFD facilita el trabajo con diagramas al simular la representación estándar de diagramas
de flujo en hojas de papel, sin embargo, la representación gráfica de las dos estructuras cíclicas que
soporta (Mientras y Para) no se apegan del todo a la representación estándar, además los elementos
gráficos no se ajustan automáticamente al texto que contienen. Otra característica es que posee un
manual de ayuda y un conjunto de ejemplos.
Figura 3 Interfaz de la herramienta freeDFD
ABEA (ver Figura 4) es una herramienta que a diferencia de las antes mencionadas, contempla las
fases de análisis del problema y planteamiento de la solución. Es todavía un prototipo inicial, no
5 DFD: Diagrama de Flujo de Datos
9
cuenta con una documentación de sus módulos. Cuenta con las siguientes estructuras: lectura,
escritura, proceso, condicionales y cíclicas (Para, Mientras, Hasta), también cuenta con los
siguientes tipos de datos: entero, real y carácter. Sin embargo, no contempla: los arreglos de ningún
tipo de dato, las llamadas a funciones, la estructura de selección múltiple, el uso de colores para
resaltar estructuras de control ni la traducción a un lenguaje de programación.
El asistente ABEA, está basado en el método de enseñanza de algoritmos centrado en 2
dimensiones (Nieva García & Arellano Pimentel, 2009): La capacidad de resolución de
problemas (la habilidad para leer un texto, interpretarlo y determinar la incógnita que una situación
plantea delimitando y entendiendo el problema) y la capacidad de abstracción (permite aislar los
detalles de un objeto o situación dada y concentrarse en los aspectos más relevantes de ésta).
El método de resolución de problemas aplicado en ABEA es el método de Polya el cual será
descrito con detalle en el capítulo 2.
Figura 4 Interfaz de la herramienta ABEA
10
1.4. OBJETIVOS
1.4.1. OBJETIVO GENERAL
Desarrollar una herramienta de software multiplataforma aplicando ingeniería de software orientada
a objetos y reingeniería de software a un prototipo inicial, que sirva como asistente básico para que
los estudiantes de algoritmos y cursos introductorios de programación adquieran, apliquen y
ejerciten la habilidad de resolver problemas mediante soluciones algorítmicas completas.
1.4.2. OBJETIVOS ESPECÍFICOS
• Aplicar un proceso de reingeniería de software al prototipo inicial para identificar su
arquitectura y el funcionamiento de los principales módulos del software.
• Realizar pruebas exhaustivas al prototipo inicial (ABEA) para primero comprender el
funcionamiento de la herramienta, luego detectar los errores que tiene y las carencias con
las que cuenta.
• Realizar cada uno de los workflows6 del proceso unificado:
o Llevar a cabo el workflow de los requisitos considerando los resultados de las
pruebas, un análisis detallado de la documentación existente y la lista de nuevas
características deseables en la herramienta, a fin de obtener el modelo de los
requisitos.
o Aplicar el workflow del análisis orientado a objetos a partir del modelo de los
requisitos y considerando los principales módulos detectados en el proceso de
reingeniería de software para obtener el modelo del análisis.
6 Flujos de Trabajo
11
o Desarrollar el workflow del diseño orientado a objetos a partir del modelo del
análisis tomando en consideración la mayor parte de la información obtenida de la
aplicación de la ingeniería inversa.
o Ejecutar el workflow de la implementación y el workflow de las pruebas para
obtener finalmente la herramienta de software.
1.5. JUSTIFICACIÓN
Es necesario contar con una herramienta de apoyo didáctico para el aprendizaje de algoritmos que
proporcione soporte para las fases de análisis y planteamiento del problema, la cual contribuirá a
eliminar los malos hábitos de resolución de problemas a prueba y error. Además, si dicha
herramienta se utiliza en conjunto con una estrategia de aprendizaje entonces se puede lograr un
aprendizaje significativo7 en los estudiantes que toman cursos introductorios de algoritmos y
programación, desarrollando una metodología sólida para la resolución de problemas la cual les
permitirá disminuir sustancialmente las dificultades al momento de aprender y aplicar nuevos
paradigmas y lenguajes de programación.
A diferencia de otras herramientas para el diseño de algoritmos mediante diagramas de flujo, la
interfaz del software que se pretende desarrollar permitirá crear de forma correcta diagramas de
flujo, evitando los errores en la simbología y en la estructura del diagrama. También permitirá el
correcto diseño de los 3 tipos de estructuras iterativas (“Para”, “Mientras” y “Hacer mientras”) con
sus correspondientes validaciones sintácticas y semánticas.
En particular, la herramienta que se plantea desarrollar en el presente trabajo se distingue del
prototipo inicial, por las siguientes ventajas:
• Traducir del diagrama de flujo a pseudocódigo y código fuente. Esto introducirá a los
estudiantes a un lenguaje de programación estructurado en particular y permitirá que el
alumno note la pequeña diferencia que existe entre la estructura de un diagrama de flujo y
la programación formal del mismo.
7 Aprendizaje permanente que produce nuevos conocimientos con base en la experiencia
12
• Visualizar las diferentes estructuras de control mediante colores distintivos. Esto logrará
ayudar a identificar rápidamente donde inician y donde terminan.
• Emplear funciones básicas de librería dentro de las operaciones de cálculo. Esto para
incrementar el número de problemas a abordar, así como sus correspondientes soluciones.
Además establecerá una base de diseño para que en un futuro sea posible utilizar funciones
desarrolladas por el usuario.
• La traza de las condiciones en la corrida de escritorio del diagrama de flujo (etapa Probar).
Con esto se permitirá observar el flujo de control con base en la evaluación de las
expresiones lógicas, facilitando la comprensión de las mismas.
• Desarrollar el software en código fuente orientado a objetos en el lenguaje Java. Con esto se
permitirá mayor portabilidad entre distintos sistemas operativos.
En la Universidad del Istmo, la herramienta a desarrollar servirá como material de apoyo en las
materias de programación a los alumnos de las distintas ingenierías así como los profesores que
imparten estas materias, ayudando en la enseñanza y aprendizaje de nuevos lenguajes de
programación consiguiendo así un mejor aprovechamiento.
La herramienta puede ser utilizada en cursos a nivel superior, en las distintas Universidades del
SUNEO8, Institutos Tecnológicos, Universidades Politécnicas, etc. Y gracias a que se prevé un
entorno intuitivo y de fácil manejo al relacionar el diseño de la interfaz de usuario de la herramienta
con las cuatro etapas de la heurística de Polya, también puede emplearse en escuelas de nivel medio
superior como preparatorias, además de cursos propedéuticos de nivel superior.
La documentación del marco de desarrollo (Proceso Unificado), especifica la estructura interna de
la herramienta, el flujo de información, los módulos que contiene y la relación que existe entre cada
uno de ellos. Esto sirve en un futuro para facilitar la implementación de nuevas funcionalidades a la
herramienta y el mantenimiento de la misma.
Además, la completa documentación del desarrollo de esta herramienta de software puede servir
como caso de estudio en materias como Ingeniería de Software y Análisis y Diseño de Sistemas.
8 SUNEO: Sistema de Universidades Estatales de Oaxaca.
13
1.6. ORGANIZACIÓN DEL DOCUMENTO
En el Capítulo 2 se aborda los principales temas que se utilizan como base metodológica para el
desarrollo del software como son: Ingeniería de software, Reingeniería de software, Compiladores,
Software educativo y la Heurística de Polya.
El Capítulo 3 describe la metodología del desarrollo y el esquema general de la herramienta,
además abarca todo el desarrollo de la herramienta de software con el método del proceso
unificado, es decir todas las fases de iniciación, elaboración, construcción y transición desde el
enfoque de los workflows de: requisitos, análisis, diseño, implementación y pruebas.
En el Capítulo 4 se muestran los resultados de las comparaciones hechas a la herramienta con otras
similares como: SICAS, RAPTOR y DFD. También el resultado de las comparaciones hechas a la
herramienta desarrollada con el prototipo inicial.
Por último el Capítulo 5 plasma las conclusiones finales y enlista las posibles mejoras que se
pueden realizar a la herramienta en el futuro.
CCAAPPII TTUULL OO 22
MARCO TEÓRICO
2.1. Introducción
2.2. Ingeniería de software
2.3. Reingeniería de software
2.4. Compiladores
2.5. Software educativo
2.6. Heurística de Polya
15
2.1. INTRODUCCIÓN
Los temas que se abordan en este capítulo servirán como base metodológica para el desarrollo del
software. El eje rector de todo el proyecto será la Ingeniería de Software aplicando el Proceso
Unificado, documentando con el Lenguaje Unificado de Modelado todos los artefactos resultantes
durante el proceso de construcción del software. Además, dado que se parte de un prototipo inicial
será necesario aplicar a este un proceso de reingeniería de software para determinar su diseño y
códigos reutilizables. Se puede decir que el ABEA básicamente es un compilador e intérprete de
diagramas de flujo que aplica un análisis por descenso recursivo a un conjunto de gramáticas libres
de contexto.
En resumen, todo lo que presentado en este capítulo se usará para generar un software educativo
que aplique la heurística de resolución de problemas de Polya y forme parte de un esquema de
aprendizaje.
2.2. INGENIERÍA DE SOFTWARE
La ingeniería de software comprende las operaciones de análisis, diseño, construcción, verificación
y gestión de entidades técnicas, particularmente en productos de software (Pressman, 2002). Sin
embargo, estas operaciones son independientes del tipo de entidades. La aplicación de ingeniería de
software, es un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y
mantenimiento del software. Se deben cuestionar y responder las siguientes preguntas:
• ¿Cuál es el problema a resolver?
• ¿Cuáles son las características de la entidad que se utiliza para resolver el problema?
• ¿Cómo se realizará la entidad (solución)?
• ¿Cómo se construirá la entidad?
• ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño
y en la construcción de la entidad?
• ¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y
mejoras de la entidad?
16
El trabajo asociado a la ingeniería de software, independientemente del tamaño, complejidad y área
de aplicación, consta de tres fases principales:
1. La fase de definición. En esta fase se responden las siguientes preguntas: ¿Qué información ha
de ser procesada?, ¿Qué función y rendimiento se desea?, ¿Qué comportamiento del sistema se
espera?, ¿Qué interfaces van a ser establecidas?, ¿Qué restricciones de diseño existen?, y ¿Qué
criterios de validación se necesitan para definir un sistema correcto? Como se puede observar,
en esta fase se centra sobre el qué. Por tanto han de identificarse los requisitos clave del sistema
y del software. Como resultado de la fase de definición tendrán lugar tres tareas principales:
ingeniería de sistemas o de información, planificación del proyecto del software y análisis de
los requisitos.
2. La fase de desarrollo. En esta fase se pretende definir cómo han de diseñarse las estructuras de
datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han
de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha
de traducirse el diseño en un lenguaje de programación y cómo ha de realizarse la prueba. El
resultado de esta fase, son tres tareas técnicas específicas que deberían ocurrir siempre: diseño
del software, generación de código y prueba del software.
3. La fase de mantenimiento. Esta fase se centra en el cambio asociado a la corrección de errores.
Sin embargo para esta fase la corrección de errores no es el único cambio que se realiza, como
algunos erróneamente piensan, sino que el mantenimiento debe constar de cuatro principales
tipos de cambios:
i. Correctivos. Cambia el software para corregir los defectos.
ii. Adaptativos. Produce modificación en el software para acomodarlo a los cambios
de su entorno externo.
iii. Mejoras. El mantenimiento perfectivo lleva al software más allá de sus requisitos
funcionales originales.
iv. Preventivos. También llamado reingeniería del software, se debe conducir a
permitir que el software sirva para las necesidades de los usuarios finales.
17
2.2.1. EL PROCESO UNIFICADO (UP)
El proceso unificado (Schach, 2005) se basa principalmente en la especificación de requerimientos
de un sistema mediante casos de uso. Posee una visión que parte de la arquitectura del sistema,
siguiendo un proceso iterativo e incremental y se fundamenta con las siguientes creencias:
• Conocer qué quieren y necesitan los usuarios potenciales es esencial para construir un
sistema exitoso.
• Las arquitecturas de los sistemas de software permiten visualizar un sistema desde múltiples
perspectivas.
• Es conveniente dividir el trabajo en etapas, donde cada iteración produce un incremento del
proyecto.
FASES DEL PROCESO UNIFICADO
El proceso unificado consta de cuatro fases las cuales son: Fase de iniciación, Fase de elaboración,
Fase de construcción y la Fase de transición.
Una fase del proceso unificado, representan un incremento significativo del proyecto. Cada paso
realizado en el proceso unificado se asocia a uno de los cinco workflows básicos y también a una de
las cuatro fases como se muestra en la Figura 5.
Figura 5 Fases del proceso unificado
18
FASE DE INICIACIÓN.
En la fase de iniciación el objetivo principal es determinar si el sistema de información propuesto es
económicamente viable.
Los primeros 2 pasos del workflow de los requisitos son comprender el dominio y construir un
modelo de negocios.
Así que el primer paso para la fase de iniciación es obtener el conocimiento del dominio. Una vez
que tenga una comprensión total del dominio, el segundo paso es construir un modelo de negocios.
El siguiente paso es identificar los casos de uso y darles prioridad. Los casos de uso deben ponerse
en el orden del riesgo que implican. Hay tres categorías de riesgos importantes: los riesgos técnicos,
el riesgo de no obtener los requisitos correctos y el riesgo de no obtener la arquitectura correcta.
Posteriormente se deben refinar los casos de uso, con esto se concluyen los pasos de la fase de
iniciación que entran en el workflow de los requisitos.
Una pequeña cantidad del workflow del análisis se realiza durante la fase de iniciación, esta consiste
en el análisis de unos cuantos casos de usos críticos, para que el diseño de la arquitectura pueda
comenzar.
Para el workflow de la implementación se construye un prototipo de pruebas, esto no quiere decir
que se construirá un prototipo rápido del proyecto pues la creación de prototipos rápidos no es parte
del proceso unificado, más bien, un prototipo de pruebas es un modelo a escala de uno o varios
segmentos del proyecto para probar la factibilidad de la construcción.
El workflow de pruebas comienza casi al principio de la fase de iniciación. El objetivo principal es
asegurar que los requisitos se hayan determinado con precisión.
FASE DE ELABORACIÓN.
En la fase de elaboración el objetivo principal es refinar los requisitos iniciales (casos de uso) y la
arquitectura, monitorear los riesgos y refinar sus prioridades, refinar el caso de la empresa y
producir un plan de administración del proyecto.
En la Figura 5 podemos observar que estas tareas corresponden a la conclusión del workflow de los
requisitos, a la realización casi total del workflow del análisis y luego al inicio del workflow de
diseño de la arquitectura.
19
LA FASE DE CONSTRUCCIÓN.
La producción de la primera versión operativa de calidad del sistema de información llamada
también versión beta, es el propósito principal de la fase de construcción. El énfasis en esta fase se
encuentra en el workflow de la implementación y en el workflow de pruebas como claramente
podemos observar en la Figura 5.
Esta fase la realizan en gran parte los programadores y el grupo de aseguramiento de la calidad, los
diseñadores juegan un papel en la redefinición del diseño. Los analistas de sistemas se ven
involucrados si se detecta una falla que requiere que los workflows previos se vuelvan a revisar o si
el problema de cambiar el objetivo provoca un cambio en los requisitos.
LA FASE DE TRANSICIÓN.
Asegurar que los requisitos del cliente se hayan cumplido es el objetivo principal de la fase de
transición. Esta fase es dirigida por la retroalimentación desde los sitios en las cuales se han
instalado las versiones beta creadas en la fase anterior. También se corrigen las fallas, los manuales
se completan y se descubren cualquier riesgo no identificado con anterioridad.
Los programadores están involucrados en esta fase pues hacen los cambios pertinentes y el grupo de
aseguramiento de la calidad prueba estos cambios. Los analistas de sistemas son necesarios cuando
se vuelve evidente una falla que requiere de un cambio en los workflows de los requisitos, del
análisis y del diseño.
2.2.2. UML
Las iniciales UML (Larman, 2004) son un acrónimo de Unified Modeling Language (lenguaje
unificado de modelado). Al ser un lenguaje, el UML puede usarse para describir los sistemas de
información desarrollados mediante el paradigma tradicional o cualquiera de las muchas versiones
del paradigma orientado a objetos, incluyendo el Proceso Unificado. En otras palabras, el UML es
una notación, no una metodología, además es una notación que puede usarse junto con cualquier
metodología.
20
A continuación se describen los elementos y diagramas UML utilizados en esta tesis:
• Caso de uso: modela la interacción entre los actores (usuarios externos de un sistema
de información) y el sistema de información mismo.
• Diagrama de caso de uso: es un diagrama individual que incorpora una serie de casos
de uso.
• Diagrama de clases: es un modelo de las clases que muestra las relaciones estáticas
entre ellas, incluyendo la asociación y la generalización.
• Diagrama de estado: muestra los estados (valores específicos de atributos de los
objetos), los eventos que provoca transiciones entre los estados (sujetos a alertas) y las
acciones tomadas por dichos objetos. Un diagrama de estado, por lo tanto, es un
modelo dinámico porque refleja el comportamiento de los objetos, es decir, la manera
en que reacciona a eventos específicos.
• Diagrama de secuencia (también conocidos como de interacción o eventos): describe
aspectos dinámicos de un sistema. Puede representar múltiples objetos de manera
independiente, incluyendo múltiples instancias de un mismo actor.
• Diagrama de paquetes: se utilizan para manejar un sistema de información grande en
paquetes relativamente independientes. Su notación UML es un rectángulo con una
etiqueta.
• Diagrama de despliegue: muestra sobre cuál componente de hardware se instala (o
despliega) cada componente de software. También muestra los enlaces de
comunicación entre los componentes de hardware.
2.3. REINGENIERÍA DE SOFTWARE
La reingeniería requiere tiempo; conlleva un coste de dinero enorme y absorbe recursos que de otro
modo podrían emplearse en preocupaciones más inmediatas (Pressman, 2002). Por lo tanto toda
21
organización necesita un modelo de procesos de ingeniería acompañado de una estrategia
pragmática para la reingeniería de software.
El modelo de proceso de reingeniería de software consta de seis actividades, en algunas ocasiones,
estas actividades se producen de manera secuencial y lineal, pero esto no siempre es así. Por esta
razón el paradigma de la reingeniería mostrado en la Figura 6 es un modelo cíclico, esto quiere
decir que cada una de las actividades presentadas, como parte del paradigma, pueden repetirse en
otras ocasiones.
Figura 6 Modelo de proceso de reingeniería de software
A continuación se describe brevemente las actividades del modelo de proceso de reingeniería de
software:
Análisis de inventario. Las organizaciones de software deberán disponer de un inventario de todas
sus aplicaciones.
Los candidatos a la aplicación de reingeniería aparecen cuando se ordena esta información en
función de su importancia para el negocio, longevidad, mantenibilidad actual y otros criterios
localmente importantes, de todas las aplicaciones activas.
El inventario deberá revisarse con regularidad ya que el estado de las aplicaciones puede cambiar en
función del tiempo y, como resultado, cambiarán también las prioridades para la reingeniería.
22
Reestructuración de documentos. Generalmente en los sistemas heredados, la documentación del
sistema es escasa, por esta razón, a continuación se muestra una serie de opciones que se deben
realizar dependiendo de la situación que se encuentre:
• Opción no 1: Si el programa es: relativamente estático, su vida útil está llegando al final, y
no es probable que experimente muchos cambios. La mejor opción es no aplicar la
reestructuración de los documentos.
• Opción no 2: A veces no es necesario volver a documentar por completo la aplicación. Se
puede optar por documentar por completo solo aquellas partes del sistema que estén
experimentando cambios en ese momento. Así la colección de documentos útil y relevante
irá evolucionando con el tiempo.
• Opción no 3: Si el sistema es primordial para el negocio, y es necesario volver a
documentarlo por completo. En este caso, un enfoque inteligente consiste en reducir la
documentación al mínimo necesario.
Ingeniería inversa. La ingeniería inversa del software es el proceso de análisis de un programa
existente, con el fin de crear una representación de programa con un nivel de abstracción más
elevado que el código fuente, es decir, la ingeniería inversa es un proceso de recuperación de
diseño. Las herramientas de la ingeniería inversa extraen del programa existente información del
diseño arquitectónico y de proceso, e información de los datos.
Reestructuración del código. La arquitectura del programa en algunos sistemas heredados, es
relativamente sólida. Sin embargo, los módulos individuales han sido codificados de forma que
hacen difíciles la comprensión, la comprobación y el mantenimiento de dichos módulos. En estos
casos, se puede reestructurar el código ubicado dentro de los módulos sospechosos.
Para llevar a cabo esta actividad, primero se analiza el código fuente mediante una herramienta de
reestructuración, después se indican las violaciones de las estructuras de programación estructurada,
y entonces se reestructura el código. El código reestructurado resultante se revisa y se comprueba
para asegurar que no se hayan introducido anomalías. Y por último se actualiza la documentación
interna del código.
Reestructuración de datos. A diferencia de la reestructuración de código, que se produce en un
nivel relativamente bajo de abstracción, la estructuración de datos es una actividad de reingeniería a
23
gran escala. La reestructuración en los datos inevitablemente causará cambios ya sea en la
arquitectura o bien de código.
Ingeniería directa (forward engineering). En la ingeniería directa no solamente se recupera la
información de diseño de un software que ya existente, sino también, utiliza esta información para
alterar o reconstruir el sistema y mejorar su calidad global. En la mayoría de los casos, el software
procedente de una reingeniería vuelve a implementar la funcionalidad del sistema existente, y añade
además nuevas funciones y/o mejora el rendimiento global.
2.4. COMPILADORES
Un compilador es un programa que recibe como entrada un programa fuente, y realiza un proceso
de traducción generando un programa objeto (ver Figura 7), durante el proceso de traducción se le
informa al usuario de la presencia de errores en el programa por medio de mensajes (Aho, Sethi,
Hill, & Ullman, 1990).
Figura 7 Esquema general de un compilador
La clasificación de los compiladores depende de cómo haya sido construido o de qué función se
supone que realiza. Frecuentemente se clasifican como: compiladores de una pasada, compiladores
de múltiples pasadas, compiladores de carga y ejecución, compiladores de depuración o
compiladores de optimación.
En este documento, el compilador utilizado será el de una pasada, en la que se aplican varias fases
de compilación en una sola pasada y consiste en la lectura de un archivo de entrada y en la escritura
de un archivo de salida.
El proceso de compilación principalmente consta de dos partes que a continuación describiremos.
24
• Análisis: En esta parte se divide al programa fuente en sus elementos componentes y crea
una representación intermedia del programa fuente. Se determinan las operaciones que
implica el programa fuente y se registran en una estructura jerárquica llamada árbol
sintáctico donde cada nodo representa una operación y los hijos de un nodo son los
argumentos de la operación.
• Síntesis: En esta parte se construye el programa objeto deseado a partir de la representación
intermedia. En las dos partes, la síntesis es la que requiere las técnicas más especializadas.
2.4.1. FASES DE COMPILACIÓN
El proceso de compilación se divide en fases que, como se muestra en la Figura 8, van
transformando al programa fuente de una representación a otra hasta llegar al programa objeto.
Figura 8 Fases de un compilador
A continuación se describen brevemente cada una de las fases del proceso de compilación
esquematizado en la Figura 8.
Administración de la tabla de símbolos. Una tabla de símbolos es una estructura de datos que
contiene un registro por cada identificador y también contiene los campos para los atributos de cada
25
identificador. La principal ventaja de la tabla de símbolos es que permite encontrar rápidamente el
registro de un identificador y almacenar o consultar rápidamente datos de ese registro. Una de las
funciones primordiales de un compilador es registrar cada uno de los identificadores utilizados en el
programa fuente y además, reunir información sobre los distintos atributos del identificador; tal
información es almacenada en la tabla de símbolos. En el caso del analizador léxico cuando detecta
un identificador en el programa fuente, el identificador se introduce en la tabla de símbolos. Cuando
se está haciendo el análisis semántico y la generación de código intermedio, se necesita saber cuáles
son los tipos de los identificadores, para poder comprobar si el programa fuente los usa de una
forma válida y así poder generar las operaciones apropiadas con ellos.
Detección e información de errores. Por lo regular, en cada fase de la compilación se detectan
errores. Cada fase debe tratar de alguna forma los errores encontrados para que se pueda continuar
con la compilación y permitir así la detección de más errores en el programa fuente.
Los errores que se encuentran en la fase léxica, por ejemplo, son cuando los caracteres restantes de
la entrada no forman ningún componente léxico del lenguaje. Sin embargo, los errores donde la
cadena de componentes léxicos quebranta las reglas de estructura (sintaxis) del lenguaje son
determinados por la fase de análisis sintáctico. Durante el análisis semántico el compilador intenta
detectar construcciones que tengan la estructura sintáctica correcta, pero que no tengan significado
para la operación implicada.
Un caso particular es el manejo de errores en modo pánico en el cual se notifica inmediatamente el
error encontrado deteniendo todo el proceso de análisis independientemente de la fase de
compilación. Es decir, ante un error la compilación se detiene para que dicho error sea corregido.
FASE DE ANÁLISIS.
Analizador léxico: A este análisis se le llama también análisis lineal o de exploración. En esta fase
principalmente se leen los caracteres en el programa fuente agrupándolos en una cadena de
componentes léxicos en los que cada componente representa una secuencia lógicamente coherente
de caracteres. A la secuencia de caracteres que forma un componente léxico se le denomina lexema
del componente. Un lexema puede ser clasificado como un identificador, una palabra clave, un
carácter de puntuación o un operador de varios caracteres, etc.
26
Analizador sintáctico: Este análisis crea una estructura jerárquica a la cadena de componentes
léxicos, que se representan por medio de árboles sintácticos. En los árboles sintácticos un nodo
interior es un registro con un campo para el operador y dos campos que contienen apuntadores a los
registros de los hijos izquierdo y derecho. Las hojas de los árboles representan cada un registro con
2 o más campos; un campo para identificar el componente léxico de la hoja, y los otros para
registrar información sobre el componente léxico. Los árboles generados en este análisis pueden ser
concretos o abstractos.
Analizador semántico: En la fase de análisis semántico se revisa el programa fuente para tratar de
encontrar errores semánticos; además se reúne la información sobre los tipos para la fase posterior
de generación de código. En esta parte se utiliza la estructura jerárquica determinada por la fase de
análisis sintáctico (árbol sintáctico) para identificar los operandos de expresiones y proposiciones.
FASE DE SÍNTESIS.
Generación de código intermedio: En esta fase se genera una representación explicita del programa
fuente. Dicha representación intermedia debe tener dos propiedades importantes; debe ser fácil de
producir y fácil de traducir al programa objeto.
Optimización de código: En esta fase el principal objetivo es tratar de mejorar el código intermedio,
de manera que resulte un código máquina más rápido de ejecutar.
Existe mucha variación en la cantidad de optimización de código que ejecutan los distintos
compiladores. En los “compiladores optimadores”, por ejemplo, tiene una parte significativa del
tiempo del compilador que se ocupa en esta fase. Sin embargo, hay optimaciones sencillas que
mejoran sensiblemente el tiempo de ejecución del programa objeto sin retardar demasiado la
compilación.
Generación de código: Esta es la fase final de un compilador y su resultado es la generación de
código objeto, que por lo general consiste en código maquina relocalizable o código ensamblador.
Sin embargo, cuando el código objeto es en realidad un programa fuente en algún lenguaje de
programación de alto nivel se reduce la complejidad de esta fase al utilizar la técnica de
concordancia de plantillas.
27
Cabe aclarar que para el compilador del software desarrollado en el presente documento, la
generación de código intermedio se utilizará para almacenar y recuperar soluciones hechas con la
herramienta, la generación de código será aplicada para la traducción que se realiza del diagrama de
flujo a lenguajes de alto nivel (C y Pseudocódigo) y la optimización de código será hecha sobre el
código generado en la traducción.
2.4.2. GRAMÁTICAS LIBRES DE CONTEXTO
Una gramática libre de contexto es una especificación para la estructura sintáctica de un lenguaje de
programación (Louden, 2004). Por ejemplo se tiene la gramática para validar la sintaxis de una
estructura de control de tipo escribir:
El ejemplo anterior, es una regla gramatical libre de contexto en BNF9 los cuales se compone de
una cadena de símbolos, donde las cadenas en minúsculas representan no terminales y las cadenas
en mayúscula representan los terminales. El primer símbolo es un nombre para una estructura
sintáctica llamada stx_escribir. El segundo símbolo es el metasímbolo “→”, seguido por una
estructura o el metasímbolo “|”. Las secuencias de símbolos y nombres de estructura dentro de cada
selección definen el diseño de la estructura. Por ejemplo, en la gramática anterior, la primera regla
define una estructura llamada stx_escribir compuesta por un infoesc, o una estructura stx_escribir
seguido de una COMA y después un infoesc. La segunda regla define una estructura llamada
infoesc que solo se compone ya sea de una CADENA o una VARIABLE.
Las reglas gramaticales determinan las cadenas legales de símbolos de token por medio de
derivaciones. Una derivación es una secuencia de reemplazos de nombres de estructura por
selecciones en los lados derechos de las reglas gramaticales. Una derivación comienza con un
nombre de estructura simple y termina con una cadena de símbolos de token. En cada etapa de una
derivación se hace un reemplazo simple utilizando una selección de una regla gramatical.
9 Backus-Naur Form (Forma Backus-Naur)
stx_escribir → infoesc | stx_escribir COMA infoesc
infoesc → CADENA| VARIABLE
28
Por ejemplo a continuación se realiza una derivación a la gramática para la expresión: CADENA
COMA VARIABLE.
En cada paso de la derivación se proporciona a la derecha la selección de la regla gramatical
utilizada para el reemplazo.
Como se logró realizar la derivación de la expresión con la gramática, entonces se concluye que
dicha expresión es correcta para la gramática dada.
La principal diferencia entre un paso de derivación y una regla gramatical es que: las reglas
gramaticales definen, mientras que los pasos de derivación construyen mediante reemplazo.
2.4.3. ANÁLISIS POR DESCENSO RECURSIVO
En términos generales, las reglas gramaticales se convierten en procedimientos que pueden ser
invocados por recursividad indirecta. De manera formal (Louden, 2004) se dice que la regla
gramatical para un no terminal A se tomará como una definición para un procedimiento que
reconocerá una A. El lado derecho de la regla gramatical para A especifica la estructura del código
para este procedimiento: la secuencia de terminales y no terminales en una selección corresponde a
concordancias de la entrada y llamadas a otros procedimientos, mientras que las selecciones
corresponden a las alternativas (sentencias case o if) dentro del código.
Como ejemplo se considera la siguiente gramática empleada en el análisis sintáctico de una
expresión aritmética:
stx_escribir => stx_escribir COMA infoesc [stx_escribir → stx_escribir COMA infoesc]
=> infoesc COMA infoesc [stx_escribir →infoesc]
=> CADENA COMA infoesc [infoesc → CADENA]
=> CADENA COMA VARIABLE [infoesc → VARIABLE]
29
Y se considera la regla gramatical stx_factor. Un procedimiento descendente recursivo que
reconoce un factor, se puede escribir en pseudocódigo de la manera siguiente:
Donde la variable token mantiene el siguiente token actual en la entrada y el procedimiento llamado
match compara el token siguiente actual con su parámetro, avanza la entrada si tiene éxito o de lo
contrario declara un error.
procedure stx_factor; begin case token of ENTERO: match(ENTERO); REAL: match(REAL ); FUNCION: match(FUNCION ); match(PIZQ ); stx_expresion; match(PDER); VARIABLE: match(VARIABLE ); MENOS: match(VARIABLE ); PIZQ: match(PIZQ ); stx_expresion; match(PDER); else error; end case; end infoesc;
stx_expresion -> stx_expresion MAS stx_termino | stx_expresion MENOS stx_termino | stx_termino
stx_termino -> stx_factor
| stx_termino PROD stx_factor | stx_termino DIV stx_factor
stx_factor -> ENTERO | REAL
| FUNCION PIZQ stx_expresion PDER | VARIABLE | MENOS | PIZQ stx_expresion PDER
30
En un analizador sintáctico descendente recursivo para la gramática de expresión el procedimiento
stx_expresion llamará a stx_termino, este a su vez llamará a stx_factor y este último llamará a
stx_expresion, de manera que todos estos procedimientos deben ser capaces de llamarse entre sí
empleando en algunos casos recursividad indirecta.
2.4.4. INTÉRPRETES
Un intérprete, al igual que un compilador, es un traductor de lenguaje, pero la diferencia radica en
que el intérprete realiza las operaciones que implica el programa fuente inmediatamente, sin generar
un código objeto como salida. Por lo tanto, en un intérprete no se produce un resultado físico
(código máquina) sino lógico (una ejecución). (Galvez Rojas & Mora Mata, 2005) Los intérpretes
usan lenguajes de órdenes para la ejecución, ya que cada operador que se ejecuta en este tipo de
lenguaje suele ser una invocación de una rutina compleja (Aho, Sethi, Hill, & Ullman, 1990).
Todos los lenguajes de programación pueden ser interpretados o compilados, sin embargo se puede
preferir un intérprete a un compilador dependiendo del lenguaje que se esté usando y de la situación
en la cual se presenta la traducción. Por ejemplo, los intérpretes se utilizan con frecuencia en
situaciones relacionadas con la enseñanza o con el desarrollo de software, donde los programas son
probablemente traducidos y vueltos a traducir muchas veces. Sin embargo es preferible usar un
compilador si lo que importa es la velocidad de ejecución, ya que el código objeto compilado, es
siempre más rápido que el código fuente interpretado, en ocasiones hasta por un factor de 10 o más
(Louden, 2004).
La principal ventaja de un intérprete es que permiten una fácil depuración. Mientras que entre los
inconvenientes, como se mencionó anteriormente, ésta la lentitud de ejecución, ya que el traducir y
ejecutar al mismo tiempo dificulta e incluso impide realizar un alto grado de optimización. Otro
inconveniente es que durante la ejecución, el intérprete debe residir en memoria, por lo que
consumen más recursos (Galvez Rojas & Mora Mata, 2005).
Según (Cueva Lovelle, 1998) los intérpretes se pueden clasificar desde el punto de vista de su
estructura en varios tipos: intérpretes puros, intérpretes avanzados o normales, e intérpretes
incrementales. En este caso, únicamente definiremos los intérpretes avanzados o normales, pues es
el que se utilizó al crear el software.
31
Los intérpretes avanzados o normales realizan toda la fase de análisis de cualquier compilador, es
decir, hacen validaciones léxicas, sintácticas y semánticas. Posterior a la fase de análisis, generan un
lenguaje intermedio que es ejecutado por ellos mismos. De esta forma en caso de errores sintácticos
no pasan de la fase de análisis. En la Figura 9 se representa el esquema general de un intérprete
avanzado.
Figura 9 Intérprete avanzado
Comúnmente las aplicaciones de los intérpretes avanzados son:
• Emulación de arquitecturas de ordenadores.
• Método para facilitar la portabilidad de aplicaciones entre distintas arquitecturas de
ordenadores.
• Fase de prueba de lenguajes y arquitecturas de máquinas abstractas, antes de construir los
traductores a código objeto de una arquitectura determinada.
En este trabajo de tesis, el intérprete avanzado es utilizado para verificar por completo la sintaxis y
coherencia del diagrama de flujo previo a ejecutar su corrida de escritorio completa y/o su
traducción, también completa, a código fuente en C.
32
2.5. SOFTWARE EDUCATIVO
Es fácil confundir un software educativo con cualquier programa de computadora que permite
cumplir o apoyar funciones educativas. Sin embargo es preciso aclarar que un software educativo
son aquellos programas diseñados específicamente con fines didácticos que permitan el desarrollo
de habilidades cognitivas (Nieva García & Arellano Pimentel, 2009).
Existen diversas clasificaciones de software educativo. Thomas Dwyer propone una taxonomía en
función del enfoque educativo predominante en: algoritmo o heurístico (Galvis Panqueva, 1988).
El software de tipo algorítmico tiene un aprendizaje vía transmisión de conocimientos, es decir, el
alumno intenta asimilar al máximo lo que se intenta transmitir. El diseño de este tipo de software
encapsula secuencias de actividades de aprendizaje que guíen al alumno a su propio ritmo. Los
sistemas tutoriales, sistemas de ejercitación y práctica, entre otros, son ejemplos de software que
encajan en el tipo de software algorítmico.
El software de tipo heurístico tiene un aprendizaje por experimentación y descubrimiento, es decir,
el alumno debe llegar al conocimiento a través de su experiencia. El diseño de este tipo de software
se enfoca hacia ambientes con abundantes situaciones que el alumno pueda explorar y/o generar.
Dentro de los heurísticos están juegos educativos, simuladores, micromundos, sistemas expertos,
entre otros.
Los aspectos que hacen la diferencia al diseñar software educativo y que no se consideran en otro
tipo de software son: qué diseñar, con qué metodología, cómo saber que el aprendizaje se está
logrando, cómo motivar y mantener motivados a los alumnos, qué funciones de apoyo deberá tener
el software, cuáles componentes son los más apropiados en la interfaz de usuario en función de los
contenidos educativos, en qué momento y cuál información se ha de presentar al usuario, entre
otros.
2.5.1. ESQUEMA DE APRENDIZAJE
Un esquema de aprendizaje (Oliver, 1999) comprende tres artefactos principales (ver Figura 10):
33
• Recursos de aprendizaje: Estos proporcionan el contenido del curso y permiten al
estudiante construir su conocimiento. Generalmente se trata de libros, notas o tutoriales.
• Actividades de aprendizaje: Establecen lo que el alumno debe hacer para aprender.
Generalmente se refiere a la resolución de ejercicios y problemas, proyectos e
investigaciones.
• Apoyos de aprendizaje: Brindan el soporte necesario para ayudar al alumno a cubrir sus
necesidades individuales de aprendizaje, por lo regular se trata de software educativo.
Figura 10 Esquema de aprendizaje
2.6. HEURÍSTICA DE POLYA
La heurística propuesta por Polya (Polya, 2005), consiste en una serie de etapas y preguntas
tendientes a ir analizando paulatinamente el texto de un problema, con la finalidad de encontrar una
solución al mismo. Para resolver un problema se necesita:
1. Comprender el problema. Ver claramente lo que se pide. Para esto es necesario
formularse las siguientes preguntas: ¿Cuál es la incógnita? ¿Cuáles son los datos
disponibles? ¿Existe alguna condición para resolver la incógnita? Haciendo uso de los
esquemas, anotaciones o dibujos que faciliten la comprensión del problema.
2. Obtener un plan de solución. Se debe captar las relaciones que existen entre los diversos
elementos, ver lo que liga la incógnita con los datos a fin de encontrar la idea de la solución
34
y pode trazar un plan. En esta etapa, es posible realizar las siguientes preguntas: ¿Es un
problema similar a otro ya visto previamente? ¿Existe algún método que use los datos
proporcionados y nos devuelva un resultado adecuado? ¿De qué otra forma se puede
plantear el problema?
3. Aplicar el plan de solución. Llevar a cabo la estrategia de solución sugerida y verificar
cada paso de ésta. Es posible formular la siguiente pregunta: ¿Cada paso es evidente y
claro?
4. Revisar la solución. Analizar la solución obtenida, a fin de estar seguros que es correcta y
satisfactoria. Es posible formular las siguientes preguntas: ¿El resultado es el que se
esperaba? ¿El resultado se puede obtener mediante otro método? ¿El método usado se
puede aplicar a otro tipo de problemas?
Las cuatro etapas de la heurística de Polya, forman un proceso iterativo, es decir, se puede avanzar
o retroceder entre cada una de las actividades propuestas (ver Figura 11).
Figura 11 Etapas de la heurística de Polya
CCAAPPII TTUULL OO 33
DESARROLLO DE LA HERRAMIENTA DE
SOFTWARE
3.1. Introducción
3.2. Workflow de los requisitos
3.3. Workflow del análisis
3.4. Workflow del diseño
3.5. Workflow de la implementación
3.6. Workflow de pruebas
37
3.1. INTRODUCCIÓN
El presente capítulo describe a detalle el software para la asistencia en el aprendizaje de algoritmos
(SAAA) y las fases de la metodología aplicada en su desarrollo.
El workflow de los requisitos hará énfasis en las principales funciones que el software ofrece, en las
restricciones propias de la aplicación y por último las características de los usuarios a los que está
dirigido el producto de software.
El workflow del análisis mostrará las clases utilizadas en el desarrollo de la herramienta; los
eventos, las respuestas y las acciones que se generan en la ejecución de la herramienta por medio de
diagramas de estado; y por último las principales interacciones de los objetos en la aplicación por
medio de los diagramas de secuencias.
El workflow del diseño organizará las principales clases utilizadas en el software en módulos y en
seguida describirá el diagrama de despliegue del sistema.
El workflow de la implementación comenzará detallando el lenguaje de programación y el IDE10
empleados en la creación del software, después se detallarán los principales algoritmos que se
reutilizaron del prototipo anterior.
Finalmente el workflow de pruebas consistirá en un conjunto de casos de prueba basados en la
ejecución, para comprobar la utilidad, fiabilidad, solidez, desempeño y corrección de la
herramienta.
Para entender de mejor manera el SAAA, a continuación se describe la metodología de desarrollo
empleada en la construcción.
10 Entorno de desarrollo integrado
38
3.1.1. METODOLOGÍA DE DESARROLLO
El proceso de reingeniería de software aplicado a la herramienta ABEA generará información que
se tomará en consideración durante el desarrollo de los workflows, sin embargo el Proceso
Unificado será la guía principal para generar el SAAA.
La Figura 12 muestra la relación de las actividades de reingeniería con las fases y workflows del
proceso unificado.
Figura 12 Esquema general para el desarrollo de la herramienta de software
Se puede observar que la reestructuración de documentos va a proporcionar información
principalmente en el workflow de los requisitos durante la fase de iniciación.
El diseño recuperado durante la ingeniería inversa de la herramienta ABEA va a influenciar en
mayor medida los workflow del análisis y del diseño durante las fases de iniciación y elaboración.
La reestructuración de datos consistirá en traducir los tipos de datos abstractos (TDA) a clases y
objetos, siempre que sea posible; esta traducción impactará significativamente a los workflows del
análisis, del diseño y de la implementación durante las fases de elaboración y construcción.
39
La reestructuración de código traducirá los algoritmos implementados en lenguaje estructurado a
una implementación en un lenguaje orientado a objetos, esta traducción tendrá mayor peso en los
workflow de la implementación durante la fase de construcción.
La ingeniería directa reconstruirá completamente el sistema adicionando nuevas características y
funcionalidades mejorando así la calidad global de la herramienta contribuyendo principalmente en
los workflows del diseño, de la implementación y de pruebas, en las fases de elaboración,
construcción y transición.
3.2. WORKFLOW DE LOS REQUISITOS
3.2.1. ESQUEMA GENERAL DE LA HERRAMIENTA
La Figura 13 presenta la concordancia que existe entre la heurística de Polya y la herramienta de
software, donde la etapa de “Entender el problema” concuerda con la etapa de Analizar ya que
realiza el estudio del enunciado inicial del problema, las respuestas a 8 preguntas que sirven para
entender mejor el problema y extraer toda la información dada en dicho enunciado y por último la
reescritura del enunciado inicial en un enunciado final que contiene toda la información obtenida
con las preguntas.
Figura 13 Concordancia entre la heurística de Polya y la herramienta de software
40
La etapa de “Obtener un plan de solución” corresponde a la etapa de Planear de la herramienta
donde se crean las variables a utilizar en la solución del problema, además a cada variable el usuario
le debe asignar un rol (entrada, salida y/o Auxiliar), un tipo de dato, un identificador, un tipo de
identificador (variable o constante) y un valor inicial, dejando a éste último como opcional ya que si
el usuario no le asigna uno el software le debe dar un valor por omisión que corresponda con su tipo
de dato.
La etapa de “Aplicar el plan de solución” concuerda con la etapa Diseñar de la herramienta en
donde el usuario elabora el algoritmo para la solución del problema, teniendo como herramientas
elementos secuenciales (Leer, Calcular y Escribir), elementos condicionales y elementos cíclicos
(Para, Mientras y Hasta). El usuario podrá compilar el algoritmo detectando errores sintácticos y
semánticos. También podrá traducir el algoritmo a pseudocódigo y/o al lenguaje de programación
estructurado C.
Por último, la etapa de “Revisar la solución” corresponde a la etapa de Probar de la herramienta,
en donde se realiza la corrida de escritorio paso a paso del algoritmo creado en la etapa Diseñar, el
cual muestra a detalle los cambios en las variables, las impresiones a pantalla y la evaluación de las
condiciones.
En la Figura 14 se presentan las etapas de la herramienta desde una perspectiva de concordancia con
los compiladores e intérpretes.
Figura 14 Herramienta desde la perspectiva de compiladores e intérpretes
41
En la Figura 14, se observa que en la etapa Planear, se genera la tabla de símbolos con todas las
variables propuestas en la solución del problema con sus correspondientes propiedades y valores.
La etapa Diseñar, al compilar el algoritmo creado, realiza un análisis por descenso recursivo para la
detección de errores sintácticos y semánticos en modo pánico. Finalmente la etapa Probar utiliza un
intérprete para la ejecución paso a paso de la corrida de escritorio del algoritmo previamente
compilado y sin errores.
3.2.2. FUNCIONALIDADES DE LA HERRAMIENTA
A grandes rasgos las funcionalidades de la herramienta se representan con el diagrama de casos de
uso de la Figura 15.
Figura 15 Diagrama de casos de uso de la herramienta
Como se puede observar en la Figura 15, la herramienta permite al usuario, insertar un elemento
secuencial como “leer”, “escribir” y “calcular”; un elemento condicional simple o doble; o una
estructura cíclicas como “Para”, “Mientras” y “Hasta” definiendo claramente la diferencia entre
42
estos ciclos. También el usuario puede seleccionar elementos del diagrama de flujo permitiendo así
copiar, cortar pegar y eliminar dicho elemento.
Una vez diseñado el diagrama de flujo, la herramienta permite al usuario realizar una compilación
para detectar errores.
La prueba de escritorio servirá al usuario para observar los cambios en los valores de las variables
en todo momento y de forma permanente indicando en número del elemento del diagrama de flujo
que provocó el cambio de valor.
Para mostrar de manera detallada la comunicación y el comportamiento del software mediante la
interacción con el usuario, es decir las funcionalidades de la herramienta, a continuación se
presentan los principales casos de uso. Cabe mencionar que en el Apéndice A se muestran los otros
principales casos de uso.
43
Tabla 1 Caso de uso Analizar
Caso de uso: Analizar
Descripción general: Permite la edición del enunciado inicial del problema y presenta una serie de 8 preguntas que deberán ser resueltas a partir del enunciado inicial para finalmente reescribir el enunciado del problema bien planteado.
Flujo básico:
Acción del actor Respuesta del sistema
1. Presiona la pestaña “Análisis”.
2. Muestra el contenido de la pestaña “Analizar”.
3. Edita el enunciado inicial del problema.
4. Contesta la pregunta actual.
5. Presiona el botón para ir a la siguiente pregunta o a la pregunta anterior.
6. Habilita la casilla de verificación del número de la pregunta que se ha contestado con al menos 2 caracteres.
Presenta la pregunta anterior o siguiente según haya seleccionado.
7. Edita el enunciado Final del problema
Precondiciones:
1. No existen
Postcondiciones:
1. El usuario debe de haber contestado las 8 preguntas para poder editar de forma correcta el enunciado final del problema.
Flujos alternos:
1. Si abre una solución. Puede completar la información que hace falta.
2. Para eliminar un elemento solo debe seleccionar el elemento deseado en cualquiera de las dos listas, y luego dar clic en el botón con el letrero de Eliminar ubicado a la derecha del botón Agregar.
3. Si la información no está completa, muestra un mensaje de advertencia al usuario cuando intenta
44
Tabla 2 Caso de uso Planear
Caso de uso: Planear
Descripción general: Permite al usuario identificar y definir las variables y constantes que utilizará a lo largo del diseño de la solución. Las variables pueden ser de entrada, salida o auxiliares.
Flujo básico:
Acción del actor Respuesta del sistema
1. Clic en la pestaña de “Planeación” de la Ventana Principal.
2. Verifica que la fase previa se haya concluido, en caso contrario, emite un mensaje de advertencia.
3. Muestra el contenido de la pestaña “Planear”.
4. Da clic en el botón agregar de la pestaña “Planeación”.
5. Agrega un nuevo elemento en la lista de elementos y en la lista de asignación de identificadores con un nombre y valores por omisión.
6. Otorga un nombre al elemento creado.
7. Activa las casillas de “Entrada”, “Salida” o “Auxiliar” dependiendo de la naturaleza de la variable.
8. En la lista de asignación de identificadores, le otorga uno de los siguientes tipos de datos: entero, real o carácter.
9. Le asigna un identificador breve al elemento.
10. Elige si el elemento será una variable o una constante.
11. Si lo desea, le asigna un valor inicial al identificador.
editar cualquiera de las otras fases para recordarle que es necesario completar la información de la fase de Análisis.
45
12. Actualiza y almacena las variables añadidas por el usuario, con sus respectivas características.
Precondiciones:
1. Debe de haberse concluido la fase de Análisis.
Postcondiciones:
1. Cada elemento agregado, debe tener un rol (entrada, proceso, salida), un tipo de dato (entero, real o caracter), un identificador (nombre de variable válido) y un tipo de identificador (variable o constante), y opcionalmente un valor inicial.
Flujos alternos:
1. Si abre una solución. Puede completar la información que hace falta.
2. Si no existe por lo menos un elemento en las listas, muestra un mensaje de advertencia al usuario cuando intenta editar cualquiera de las otras fases para recordarle que es necesario completar la información de la fase de Planear Solución.
Tabla 3 Caso de uso Diseñar
Caso de uso: Diseñar
Descripción general: El usuario podrá diseñar el algoritmo para resolver el problema con las herramientas que la herramienta ofrece.
Flujo básico:
Acción del actor Respuesta del sistema
1. Clic en la pestaña de “Diseñar” de la Ventana Principal.
2. Verifica que la fase previa se haya concluido, en caso contrario, emite un mensaje de advertencia.
3. Muestra el un diagrama de flujo por omisión conteniendo solo los elementos “Iniciar” y “Finalizar”. Si hay variables creadas en la fase de Planeación, muestra también el elemento de “Inicializar”.
46
4. Selecciona una flecha que permite la inserción (resaltada de color verde).
5. Da clic en el botón del elemento que desea insertar.
6. Dependiendo del tipo de elemento a insertar, se ejecuta el caso de uso correspondiente.
Precondiciones:
1. Si existen variables agregadas en la fase de Planeación, cada variable debe tener un respectivo: rol, tipo de dato, identificador y tipo de identificador. Y éstos deben estar correctos.
Postcondiciones:
1. El diagrama de flujo creado debe estar compilado y sin errores para poder traducirlo o probarlo.
Flujos alternos:
1. Si abre una solución. Puede insertar nuevos elementos o eliminar existentes al diagrama de flujo.
Tabla 4 Caso de uso Compilar
Caso de uso: Compilar
Descripción general: Compila la solución diseñada en la fase de diseño.
Flujo básico:
Acción del actor Respuesta del sistema
1. Da clic en el botón Compilar ubicada la parte inferior izquierda de la fase de diseño.
2. Realiza un análisis por descenso recursivo del diagrama de flujo creado.
3. Si no existe ningún error en el análisis, muestra un cuadro de mensaje informando al usuario que la compilación ha sido satisfactoria.
Precondiciones:
1. Debe de haber un diagrama de flujo creado en la fase Diseñar.
47
Postcondiciones:
1. Debe mostrar un mensaje al usuario con la información del resultado final de la compilación.
Flujos alternos:
1. Si existe un error en la compilación, se detecta el error en modo pánico y muestra un cuadro de mensaje con la información del tipo de error y la ubicación aproximada del mismo
Tabla 5 Caso de uso Probar
Caso de uso: Probar
Descripción general: Realiza paso a paso la corrida de escritorio del diagrama de flujo creado en la fase de diseño.
Flujo básico:
Acción del actor Respuesta del sistema
1. Da clic en la pestaña “Probar”.
2. Enumera y muestra el diagrama de flujo creado en la fase de diseño.
3. Da clic en el botón “Inicio” ubicado en la parte inferior del diagrama.
4. Verifica que el diagrama de flujo haya sido compilado y no tenga errores.
5. Ejecuta el elemento “Iniciar” y dibuja una flecha en la siguiente estructura.
6. Cambia la etiqueta del botón de “Inicio” por la etiqueta de “Siguiente”.
7. Da clic en el botón de Siguiente ubicado en la parte inferior del diagrama de flujo.
8. Ejecuta el elemento actual.
9. Dibuja la tabla resultante de la prueba actual.
10. Cambia la flecha blanca a la siguiente estructura.
48
11. Ejecuta la estructura “Finalizar”
12. Inicializa todos los valores a null.
13. Muestra un cuadro de diálogo con el mensaje: “Ejecución Finalizada”
14. Da clic en aceptar
15. Cierra el cuadro de diálogo y se termina la ejecución.
Precondiciones:
1. Debe de haber sido compilado de manera satisfactoria, el diagrama de flujo creado en la fase Diseñar.
Postcondiciones:
1. Debe mostrar en la tabla resultante cada uno de los cambios realizados a las variables, así como cada una de las salidas a pantalla.
Flujos alternos:
1. Si el elemento a ejecutar es una estructura de tipo Leer, la herramienta muestra un cuadro de diálogo donde el usuario digita la información de entrada, luego el sistema valida si la información coincide con el tipo de dato deseado, y finalmente cambia el valor en la tabla de símbolos de la variable que se encuentra dentro de la estructura, con la información de entrada.
3.2.3. RESTRICCIONES
El SAAA no incluye las estructuras de selección múltiple utilizadas como alternativa a los múltiples
anidamientos de condiciones.
Otra restricción de la herramienta es que aún no se permiten desarrollar procedimientos o funciones
definidas por el usuario. Sin embargo, el diseño ha de facilitar esta funcionalidad en futuras
modificaciones y mejoras.
La herramienta tampoco permite el uso de arreglos, ni del empleo de los tipos de datos definidos
por el usuario, es decir estructuras o registros.
49
El copiado de los elementos condicionales y cíclicos, en la etapa del diseño, solo se realiza del
elemento seleccionado, es decir, no se copia los elementos que se encuentran dentro de la estructura
(Por ejemplo: anidamientos).
El diagrama de flujo solo puede ser traducido a pseudocódigo y a lenguaje C, sin embargo el diseño
de la gramática permite la traducción a prácticamente cualquier lenguaje estructurado.
En la etapa de pruebas, la corrida de escritorio solo puede ser paso a paso hacia delante, es decir no
se tendrá la posibilidad de deshacer la ejecución de un elemento del diagrama de flujo, ni ejecutarlo
todo de corrido de manera secuencial.
3.2.4. CARACTERÍSTICAS DE LOS USUARIOS
Como se mencionó en la sección 3.2.2 en la Figura 15, existen dos tipos de usuarios: el usuario
alumno y el usuario profesor, estos usuarios deben tener conocimientos indispensables para la
utilización sin problemas de la herramienta. Por lo tanto ahora se enlistan las características para los
tipos de usuarios.
USUARIO PROFESOR
Este tipo de usuario debe tener conocimiento y experiencia en el uso de software de computadoras
personales (PC), dominio de cada uno de los temas contenidos en la materia de algoritmos, lo
anterior le permitirá guiar a sus alumnos en la enseñanza de la materia y la herramienta. También se
requiere que posea conocimiento en lenguajes de programación, para poder señalar la facilidad de
traducción de los algoritmos a cualquier lenguaje de programación estructurado, en particular al
lenguaje de programación C. Además es altamente recomendable que este usuario tenga
conocimiento y experiencia en la docencia de clases teóricas y prácticas.
USUARIO ALUMNO
50
Para este tipo de usuario la lista de conocimientos previos es menor a la del profesor, pues el
objetivo de este software es facilitar al alumno el análisis, planteamiento, diseño y prueba de una
solución al problema dado. Por lo tanto, el alumno solo debe tener conocimientos y experiencia en
el uso de software de PC, en el concepto matemático de variable y dominio en álgebra básica.
3.3. WORKFLOW DEL ANÁLISIS
3.3.1. DIAGRAMA DE CLASES
Antes de empezar, cabe señalar que los diagramas de clases en UML se componen de tres partes: el
nombre de la clase, los atributos de la clase y los métodos de la clase como se muestra en la Figura
16.
Figura 16 Estructura de un diagrama de clases
A continuación se describen los principales diagramas de clases que corresponden a las etapas de la
heurística de la herramienta.
51
Figura 17 Diagrama de clases para ClaseAnalisis
La ClaseAnalisis (ver Figura 17) corresponde a la etapa Analizar de la herramienta. Esta clase
contiene un atributo llamado Enunciado_Inicial, que servirá para almacenar el enunciado inicial del
problema. Un atributo de tipo arreglo de ocho elementos llamado Preguntas, que contienen las ocho
preguntas necesarias para el análisis del enunciado inicial del problema. Un atributo de tipo arreglo
de ocho elementos llamado Ayuda para almacenar el texto de ayuda para cada elemento del atributo
Pregunta. Un atributo de tipo arreglo con ocho elementos llamado Respuestas que almacenará cada
una de las respuestas y su estado (resuelta y sin resolver) a las preguntas hechas para el análisis del
enunciado inicial del problema. Y por último un atributo llamado Enunciado_Final que servirá para
almacenar el enunciado final reescrito por el usuario con toda la información extraída del análisis
del enunciado inicial del problema.
La ClaseAnalisis contiene también seis métodos necesarios para el funcionamiento de la clase en la
etapa Analizar. Los nombres de cada uno de los métodos dan una idea general del funcionamiento
del mismo, por ejemplo como se observa en la Figura 17 el método Obtener_Enunciado_Inicial() lo
que realiza es la obtención del enunciado inicial dada por el usuario. En el método llamado
Validar_Etapa(), se verifica que: se haya escrito el enunciado inicial, todas las preguntas hayan sido
contestadas y por último verifica que el enunciado final también se haya reescrito.
52
Figura 18 Diagrama de clases para ClasePlaneacion
La ClasePlaneacion (ver Figura 18), corresponde a la etapa Planear de la herramienta. La
componen: un atributo llamado Lista_de_Elementos que como su nombre lo indica, es de tipo lista
y almacena los elementos agregados en la etapa, necesarios para la solución del problema; un
atributo llamado Analizador_Lexico para el análisis léxico de los identificadores asignados a los
elementos, por ejemplo, se valida que no tengan espacios o caracteres no válidos.
También la ClasePlaneacion, contiene cinco métodos necesarios para la edición de los elementos.
En el método llamado Validar_Etapa() se verifica que el nombre del identificador y propiedades de
cada uno de los elementos sean correctos. El método llamado Agregar_nuevo_Elemento(), agrega
un nuevo elemento en la lista de elementos y en la lista de asignación de identificadores, el método
Eliminar_Elemento() remueve en ambas listas el elemento seleccionado.
La clase DiagramaFlujo (ver Figura 19) corresponde a la etapa Diseñar de la herramienta. Está
formada por cinco atributos y diecisiete métodos necesarios para la edición del diagrama de flujo.
Los atributos llamados Estructura_inicio y Estructura_fin, son los que denotan el inicio y el final
del diagrama de flujo, entre estos se pueden insertar distintos tipos de estructuras. El atributo
llamado Portapapeles es útil para almacenar de manera temporal las estructuras copiadas o
cortadas. El atributo Area como su nombre lo indica, es el área que ocupa el diagrama de flujo,
necesario para los reacomodos que se realizan al insertar o eliminar elementos.
Los métodos de la clase DiagramaFlujo son elementales para la edición y pintado del diagrama.
Con ellos se logra: obtener, insertar, copiar, cortar, pegar y eliminar los elementos (estructuras).
También se puede reacomodar, mostrar, guardar, duplicar, numerar y traducir.
53
Figura 19 Diagrama de clases para DiagramaFlujo
La ClaseEjecutar (ver Figura 20) corresponde a la etapa Ejecutar de la herramienta. Contiene cinco
atributos y diecisiete métodos, que hacen posible la ejecución del diagrama de flujo creado en la
fase de diseño de la herramienta. Los atributos llamados Lista_Tuplas_Ejecucion y
Tupla_Encabezado son de tipo lista y conforman cada una de las filas de la tabla que muestra la
corrida de escritorio. El atributo Analizador_Lexico en esta clase solo realiza la búsqueda de las
variables que va encontrando a su paso en la Tabla de símbolos (atributo llamado Tabla_Simbolos).
En el atributo Lista_Condiciones se almacenarán las condiciones que se van encontrando en la
ejecución y la evaluación de la misma (verdadera, falsa) para añadirlas en la traza del diagrama.
Los métodos de la ClaseEjecutar, son los necesarios para: la ejecución de cada una de las
estructuras del diagrama de flujo; también para realizar las operaciones: lógicas, comparativas, y
aritméticas (Calcular_operacion(), expresión(), termino(), factor()); para la identificación de tipos
de datos (cadena()); y para buscar las variables en la tabla de símbolos (obtenerVar()).
54
Figura 20 Diagrama de clases para ClaseEjecutar
Los cuatro diagramas de clases antes mencionados, son solo una pequeña parte de la estructura
general de la herramienta. Por ello y para mayor comodidad en la Tabla 6 se tiene una descripción
general muy breve de estas y las otras clases que conforman la herramienta.
Tabla 6 Descripción breve de las clases que componen el software
NOMBRE DE LA
CLASE
DESCRIPCIÓN
ClasePrincipal Esta es la clase principal de la aplicación, la que contiene el Main del programa. También contiene el diseño de la ventana principal de la herramienta y la funcionalidad de cada elemento.
CDLeer Esta clase contiene el diseño y funcionalidad del cuadro de diálogo que se ocupa al tomar valores en el momento de ejecución o prueba del diagrama de flujo.
CDPara Contiene el diseño y funcionalidad del cuadro de diálogo utilizado al introducir la información necesaria para la creación o modificación de un ciclo Para.
55
CD_Estandar Contiene los códigos java para la creación automática de cuadros de diálogos estándar como lo son: Aviso, Error, Advertencia y confirmación.
CTexto Calcula las dimensiones de altura y anchura de una cadena de texto recibida, y además la traza en la posición y color que se le indique.
ClaseElemento Es la clase que contiene todas las propiedades de los elementos (variables y constantes) declarados en la etapa Planear.
ClaseRespuesta Clase para las respuestas que se obtienen de las preguntas en la etapa Analizar.
ComboTipoDato Combo que contiene los tipos de datos de la lista de asignación de identificadores en la etapa Planear.
Conds Clase que representa las condiciones al momento de ejecución de la etapa probar.
CuadroDlg Cuadro de diálogo que se utiliza para capturar el código de algunas estructuras al momento de insertarlas, por ejemplo, un elemento secuencial, condicional y algunos cíclicos (Mientras y hasta).
Dato Clase que contiene los atributos de la clase ElementoDF, es decir la información asociada a un elemento del diagrama de flujo.
ElementoDF Clase que contiene los métodos y atributos del elemento que compone un Diagrama de flujo.
EscuchadorCelda Escucha las modificaciones que se realiza en cada celda de la lista de elementos y la lista de asignación de identificadores de la etapa Planear.
JP_Ayuda Formulario que muestra la ayuda a las preguntas en la etapa de Análisis.
Lienzo Es el lienzo donde se dibuja el diagrama de flujo.
LienzoPruebasDF Lienzo que se encarga de dibujar el diagrama de flujo enumerado en la etapa Probar.
LienzoTablaEjec Lienzo que se encarga de dibujar la tabla que muestra los cambios en las variables.
ObjEtiqueta Clase que realiza el análisis léxico para la apertura de archivos.
ObjLexico Clase que realiza el análisis léxico de la compilación del diagrama de flujo.
Rectangulo Denota el área que abarca un elementoDF, del diagrama de flujo.
TraducirA Cuadro de diálogo que muestra las opciones para traducir el diagrama de flujo.
TupEjec Contiene los datos de la Fila actual de la tabla en ejecución de la etapa Probar.
Vars Representa las variables del diagrama de flujo.
ClaseCompilar Clase encargada del análisis sintáctico y semántico del código asociado a los elementos
56
del diagrama de flujo.
anstxAbrir Clase que carga una solución guardada previamente. Realiza un chequeo sintáctico del archivo afín de garantizar archivos no corruptos.
cd_Abrir Contiene el cuadro de diálogo estándar para abrir archivos
Cd_Guardar Contiene el cuadro de diálogo estándar para guardar archivos.
jd_Preguntar Cuadro de diálogo con el que la herramienta pregunta si se desea guardar los cambios.
unNumero Representa un número ya sea de tipo entero o real.
JTabbedPane Clase que sirve como panel para contener pestañas.
JTable Clase que sirve para crear tablas.
Una vez descritas todas las clases, se procede a mostrar el diagrama de clases UML completo en la
Figura 21. En este es posible apreciar relaciones de composición y agregación entre las distintas
clases que conforman el sistema. Cabe mencionar que en el Apéndice B se muestra los principales
diagrama de clases listadas en la Tabla 6.
57
Figura 21 Diagrama de clases UML para el sistema
58
3.3.2. DIAGRAMAS DE ESTADO
La Figura 22 muestra el diagrama de estados del sistema, donde se identifican las etapas de la
heurística de Polya, así como las funciones estándar (Nuevo, Abrir y Guardar) aplicadas la
herramienta. Este diagrama de estados es la aplicación de la Figura 13 contenida en el subtema
3.2.1 donde se muestra la relación de las etapas de la heurística de Polya con las etapas del sistema.
Figura 22 Diagrama de estados del sistema
En el diagrama de estados de la Figura 22 se observa que el SAAA permite al usuario acceder a
cualquier pestaña de la herramienta sin importar el orden (aunque no tenga sentido acceder a la
pestaña Probar sin pasar por la pestaña Diseñar), sin embargo la herramienta muestra mensajes de
advertencia cuando el usuario pasa a otra pestaña dejando la actual sin concluir o incorrecta, pero le
permite continuar. No obstante el orden correcto que se debe aplicar para crear una solución con la
herramienta, es la que se muestra en el diagrama de estados de la Figura 23.
El orden correcto para la utilización de la herramienta inicia con la etapa Analizar, sigue con la
etapa Planear, continua con la etapa Diseñar y concluye con la etapa Probar. Opcionalmente la
herramienta le permite al usuario traducir al lenguaje C o Pseudocódigo el diseño del diagrama de
flujo. Al transitar de la etapa Analizar a la etapa Planear, se verifica que los datos sean correctos y
completos, de no ser así se le notifica que no se ha concluido satisfactoriamente la etapa Analizar.
Al transitar de la etapa Planear a Diseñar se validan las propiedades de los elementos existentes, si
hay algún tipo de omisión o error en las propiedades, se lanza el mensaje de error correspondiente al
59
usuario. Para transitar de la etapa Diseñar a la etapa Probar, se debe tener una compilación
satisfactoria del diagrama de flujo construido, de igual forma para poder traducir el diagrama a
lenguajes de alto nivel, también es necesario tener una compilación satisfactoria previa.
Figura 23 Diagrama de estados en una sesión normal utilizando la herramienta
3.3.3. DIAGRAMAS DE SECUENCIA
A continuación se detallan los diagramas que muestran las secuencias que pudieran desarrollarse
entre los objetos para asegurar que la lógica que se utiliza sea correcta y que correspondan a los
casos de uso especificados en la Sección 3.2.
Para el caso de uso Analizar de la Tabla 1 (Sección 3.2.2), se tiene el diagrama de secuencia para la
etapa Analizar que se muestra en la Figura 24 donde se observa que el diagrama de secuencias
inicia ejecutando el caso de uso Analizar al mostrar la pestaña Analizar. Para continuar con la
secuencia, el usuario debe introducir el enunciado inicial, escribir la respuesta a la pregunta actual y
dar clic en el botón siguiente. Se toma la respuesta actual y se almacena en ClaseAnalisis, luego se
valida la respuesta para activar la casilla en el JTPEtapas, (repitiéndose el paso 4-9 para las ocho
preguntar, ver Figura 24). Por último, se espera que el usuario introduzca el enunciado final del
problema y de clic en una pestaña distinta a la actual (Pestaña Analizar) para que se obtenga toda la
información dada por el usuario y se almacene en ClaseAnalisis terminando así con el diagrama de
secuencia para la etapa Analizar.
60
Figura 24 Diagrama de secuencia para la etapa Analizar
Figura 25 Diagrama de secuencia para la etapa Planear
Para el caso de uso Planear de la
Tabla 2 vista en la Sección 3.2.2, se tiene el diagrama de secuencia para la etapa Planear mostrado
en la Figura 25. Que comienza al mostrar la pestaña correspondiente. Para continuar con la
secuencia, se espera que el usuario dé clic en el botón agregar, inmediatamente se crea un nuevo
61
elemento de ClaseElemento y añade dicho elemento a ClasePlaneacion se agrega una fila a la tabla
JTableElementos y se muestra en la pestaña del JTPEtapas. Luego el usuario continúa con la
secuencia añadiendo las propiedades correspondientes al elemento creado, por lo tanto, se actualiza
la información del elemento en ClasePlaneación y también en las tablas JTableElementos y
JTableIdentificadores.
Cabe señalar que la secuencia mostrada en la Figura 25, es para agregar un solo elemento. Sin
embargo, la secuencia del paso 2 al 12 se repite para agregar un elemento el número de veces que el
usuario desee.
Figura 26 Diagrama de secuencia para construir un diagrama de flujo en la fase Diseñar
Para el caso de uso Diseñar de la Tabla 3 vista en el Sección 3.2.2, se tiene el diagrama de
secuencia para construir un diagrama de flujo en la fase Diseñar que se muestra en la Figura 26.
Donde comienza mostrando la pestaña Diseñar del JTPEtapas, luego repintando el lienzo con la
información solicitada de la clase DiagramaFlujo. Y continuando con la secuencia hasta que el
usuario dé clic en una flecha insertable. La clase DiagramaFlujo identifica y obtiene el elemento
seleccionado de la clase DiagramaFlujo, e inmediatamente dibuja en la clase Lienzo un indicador
de selección. Se espera que el usuario elija y de clic en un botón de la paleta de estructuras. Se crea
y visualiza un nuevo cuadro de diálogo de la clase CuadroDLG, donde el usuario introduce el
código y da clic en el botón aceptar del mismo cuadro de diálogo. La clase CuadroDLG envía el
código a la clase ObjLexico para que éste, busque la(s) variable(s) en ClasePlaneación. Luego, en la
62
clase DiagramaFlujo se inserta el elemento, reacomoda el diagrama y muestra el nuevo diagrama
de flujo con el elemento insertado.
Para el caso de uso Compilar de la Tabla 4 vista en el Sección 3.2.2 se tiene el diagrama de
secuencia para compilar un diagrama de flujo (ver Figura 27). Que comienza cuando el usuario da
clic en el botón compilar, inmediatamente se crea un nuevo objeto de la ClaseCompilar el cuál
solicita el diagrama de flujo creado en la etapa anterior para después analizar sintáctica y
semánticamente el diagrama de flujo trabajando a la par con un ObjLexico. Al terminar el
compilado del diagrama se envía el resultado de la compilación a la clase CD_Estandar quien
muestra los errores al usuario o el mensaje de “compilación correcta”.
Figura 27 Diagrama de secuencia para compilar un diagrama de flujo en la fase Diseñar
Para el caso de uso Probar de la Tabla 5 vista en el Sección 3.2.2, se tiene el diagrama de secuencia
para un escenario de ejecución (Hola mundo) en la etapa probar. Cabe señalar, que este escenario se
ejecuta después de haber compilado el diagrama de flujo en la etapa Diseñar y la respuesta de la
ejecución ha sido satisfactoria.
El diagrama de secuencia de la Figura 28 comienza cuando el usuario da clic en el botón inicio de la
pestaña Probar contenida en JTPEtapas, inmediatamente se cambia el letrero del botón inicio a
siguiente y se toma el primer elemento de la clase DiagramaFlujo (elemento iniciar), se dibuja la
flecha en la clase LienzoPruebasDF para indicar el elemento actual. Después se crea un nuevo
elemento de tipo LienzoTablaEjec dicho elemento servirá para mostrar la traza de la corrida de
escritorio. También se crea un elemento de tipo ClaseEjecutar que como su nombre indica, se
63
encarga de la ejecución de los elementos del diagrama de flujo. Con esta clase, se ejecuta el
elemento iniciar y se crea un nuevo elemento de tipo TupEjec que son las filas que contienen la
información de la ejecución actual y que conforman la tabla de la corrida de escritorio. El elemento
de tipo TupEjec solicita la tabla de símbolos a la clase Vars y se agrega a la ClaseEjecutar. Se
avanza al elemento siguiente (elemento Escribir) y se dibuja la flecha índice en la clase
LienzoPruebasDF para indicarle al usuario el elemento próximo a ejecutar. Se agrega la fila
(elemento tipo TupoEjec) con la información de la ejecución a la tabla del LienzoTablaEjec, por lo
tanto se repinta dicho lienzo. Para continuar con la ejecución, el usuario debe dar clic en el botón
siguiente (antes llamado inicio) y se ejecuta el elemento Escribir con la ClaseEjecutar. Se crea un
nuevo elemento del tipo TupEjec quien solicita información a la clase Vars para después
modificarlas con respecto a la ejecución. Luego se agrega la tupla a la ClaseEjecutar y se avanza al
elemento siguiente (elemento Finalizar). Se dibuja la Flecha índice en la clase LienzoPruebasDF,
después se agrega la fila a la tabla del LienzoTablaEjec y se repinta dicho lienzo. Para seguir con la
secuencia, es necesario que el usuario de clic por última vez en el botón siguiente, para ejecutar el
elemento Finalizar con la ClaseEjecutar. Se crea un último elemento del tipo TupEjec, quien
solicita la información necesaria a la clase Vars para ejecutar el elemento Finalizar. Se agrega el
elemento TupEjec a la ClaseEjecutar y al LienzoTablaEjec. Por último, se muestra al usuario el
letrero de “Ejecución Finalizada” con la clase CD_Estandar.
64
Figura 28 Diagrama de secuencia para un escenario de ejecución (Hola mundo) en la etapa Probar
65
3.4. WORKFLOW DEL DISEÑO
Tal como se menciona en (Schach, 2005). En el paradigma tradicional la fase de diseño consta de
dos pasos. Primero, se lleva a cabo el diseño arquitectónico. Aquí el sistema de información se
descompone en módulos. Como las clases son módulos, gran parte de este paso corresponde a la
extracción de clases del workflow del análisis.
El segundo paso del diseño en el paradigma tradicional es el diseño detallado. Aquí los algoritmos y
las estructuras de datos se diseñan para cada módulo.
En ambos paradigmas gran parte del diseño detallado incluye funciones de programación
específicas (tales como los parámetros, los elementos que se transfieren entre los módulos cuando
se invocan en el momento de ejecución). El apéndice B contiene el diseño de las principales clases
esquematizado con sus correspondientes diagramas de clase.
3.4.1. DIAGRAMA DE PAQUETES
A continuación se describe la clasificación de las clases de la Figura 21 Diagrama de clases UML
para el sistema, mostrada en la Sección 3.3.1 en paquetes, para dar un orden al diseño de la
aplicación y facilitar en un futuro el mantenimiento del software y la posible reutilización de los
paquetes.
PaquetePrincipal
El paquete llamado PaquetePrincipal (ver Figura 29) agrupa las clases: JP_Ayuda,
ComboTipoDato, EscuchadorCelda, Lienzo, LienzoTablaEjec, LienzoPruebasDF y ClasePrincipal.
Este paquete contiene las clases, atributos y métodos necesarios para que interfaz principal de la
herramienta funcione correctamente. Incluye los paneles de ayuda, las clases usadas como lienzos
para dibujar en la etapa Diseñar y en la etapa Probar, el combo para elegir el tipo de dato de los
elementos y los escuchadores de celdas para las listas, ambos usados en la etapa Planear. También
incluye los botones de las funcionalidades estándar como: abrir, guardar, guardar como y nuevo;
además de las pestañas que definen cada una de las etapas de la heurística de Polya, y los elementos
que las conforman.
66
Figura 29 Diagrama del PaquetePrincipal
PaqueteAnalizar
El paquete llamado PaqueteAnalizar de la Figura 30, agrupa las clases: ClaseAnalisis y
ClaseRespuesta.
Esta clase tiene como principal objetivo, almacenar toda la información para la etapa Analizar de la
herramienta y contener las clases, métodos y objetos que hacen que dicha etapa funcione
correctamente. La información almacenada son los enunciados: inicial y final del problema, así
como la lista de tipo ClaseRespuesta donde se encuentran las respuestas a las ocho preguntas
hechas en la etapa y el estado de cada una de ellas (contesta o no contestada).
Figura 30 Diagrama del PaqueteAnalizar
PaquetePlaneacion
El paquete llamado PaquetePlaneacion mostrado en la Figura 31, agrupa las clases:
ClasePlaneacion y ClaseElemento.
67
Este paquete tiene como principal función almacenar toda la información de la etapa Planear.
Incluye los métodos y objetos que hacen posible el funcionamiento correcto de la etapa, y también
incluye la lista de elementos del tipo ClaseElemento, donde la ClaseElemento contiene cada una de
las propiedades de los elementos como: Nombre, tipo de rol, tipo de dato, identificador, tipo de
identificador y valor inicial.
Figura 31 Diagrama del PaquetePlaneacion
PaqueteDiagramaFlujo
El paquete llamado PaqueteDiagramaFlujo (ver Figura 32) agrupa las clases: DiagramaFlujo,
ElementoDF, Rectangulo, Dato y CTexto.
La función principal del este paquete es almacenar, facilitar la edición y uso del diagrama de flujo
creado en la etapa Diseñar con las clases: DiagramaFlujo y ElementoDF. Guarda las respectivas
propiedades de cada uno de los elementos que conforman dicho diagrama, con las clases:
Rectangulo y Dato. Y con la clase CTexto facilita el trazado y ajuste automático de cadenas al
diagrama.
Figura 32 Diagrama del PaqueteDiagramaFlujo
PaqueteCompilar
El PaqueteCompilar mostrado en la Figura 33 agrupa las clases: anstxAbrir, ObjEtiqueta,
ClaseCompila y ObjLexico.
68
La función principal de este paquete es el analizar léxica, sintáctica y semánticamente el texto
recibido. Con las clases ClaseCompilar y ObjLexico se realiza la compilación del diagrama de flujo,
para detectar errores. Y con las clases anstxAbrir y ObjEtiqueta se verifica que el archivo a cargar,
no sea un archivo corrupto.
Figura 33 Diagrama del PaqueteCompilar
PaqueteEjecutar
El paquete llamado PaqueteEjecutar que se muestra en la Figura 34 agrupa las clases: TupEjec,
unNumero, ClaseEjecutar, Vars y Conds.
Este paquete se encarga principalmente de la ejecución de cada uno de los elementos del diagrama
de flujo con la clase principal llamada ClaseEjecutar. Las clases unNumero y Vars son clases
auxiliares para guardar las variables, tipos de datos y sus respectivos valores. La clase Conds
almacena las condiciones que va encontrando a su paso y junto con su evaluación. Y con la clase
TupEjec se crea y almacena las filas de ejecución para la traza de la corrida de escritorio con sus
respectivos cambios de variables, salida de pantalla y/o evaluación de las condiciones.
Figura 34 Diagrama del PaqueteEjecutar
69
PaqueteCDAuxiliares
El paquete llamado PaqueteCDAuxiliares agrupa las clases: cd_Guardar, jd_Preguntar, TraducirA,
CDPara, CuadroDlg, CDLeer, cd_Abrir y CD_Estandar.
Este paquete contiene todos los cuadros de diálogo que muestran al usuario mensajes de error,
mensajes de advertencia, mensajes de notificación, mensajes de confirmación, cuadros de diálogos
para la entrada de datos y cuadros de diálogos estándar para abrir y guardar archivos.
Figura 35 Diagrama del PaqueteCDAuxiliares
3.5. WORKFLOW DE LA IMPLEMENTACIÓN
3.5.1. PLATAFORMA DE IMPLEMENTACIÓN
El SAAA, fue desarrollado con el lenguaje de programación Java (Oracle) y la herramienta
NetBeans, utilizando principalmente las estructuras y clases de: AWT, SWING. Que se describen
junto con las razones de su elección, a continuación.
JAVA
La razón fundamental para la elección del lenguaje son las características principales que ofrece
Java respecto a cualquier otro lenguaje de programación como son:
70
� Simple: Por ejemplo, con Java, no es necesario preocuparse de liberar memoria ya que el
garbage collector (reciclador de memoria dinámica) se encarga de ello.
� Orientado a objetos: Soporta las tres características propias del paradigma orientado a
objetos: encapsulamiento, herencia simple y polimorfismo.
� Verificación de errores: Ayuda a detectar errores lo antes posible en el ciclo de desarrollo.
Realiza verificaciones en busca de problemas tanto en tiempo de compilación como en
tiempo de ejecución.
� Arquitectura neutral: Cualquier máquina que tenga el sistema de ejecución (run-time)
puede ejecutar el código objeto Java, independientemente de la maquina en que ha sido
generado.
� Portable: Más allá de la portabilidad básica por ser de arquitectura independiente, Java
implementa otros estándares de portabilidad para facilitar el desarrollo.
� Interpretado: El intérprete Java (sistema run-time o también llamado máquina virtual)
puede ejecutar directamente el código objeto.
� Dinámico: Java no intenta conectar todos los módulos que comprenden una aplicación
hasta el mismo tiempo de ejecución.
� Difundido: Java se ha convertido en el lenguaje más difundido en este momento. Por lo
tanto hace que sea muy fácil encontrar documentación, código ejemplo y muchos otros
recursos referentes al lenguaje por lo tanto le proporciona mayor versatilidad.
NETBEANS
Es un entorno de desarrollo integrado (siglas en ingles IDE). Que permite a los programadores
escribir, compilar, depurar y ejecutar programas Java o cualquier otro lenguaje de programación.
Esta herramienta fue elegida para el desarrollo del software porque:
� Es un producto libre, gratuito y sin restricciones de uso.
71
� Soporta varios tipos de lenguaje entre ellos Java.
� Es amigable para el desarrollo de interfaces gráficas.
� Genera el byteCode de manera automática.
� Facilita la escritura de código.
La versión del NetBeans IDE utilizado en la construcción de la herramienta es el 6.9.1 (ver Figura
36). Fue ésta versión la más actual en el momento de iniciar con la programación del software.
Figura 36 NetBeans 6.9.1
BIBLIOTECAS DE CLASES JAVA
Las bibliotecas de clases Java (Quintas, 2008) que se utilizan en la implementación de la
herramienta son:
� AWT: Es el acrónimo del Abstract Window Toolkit (Herramientas de ventana abstracta) de
Java, para el desarrollo de interfaces gráficas de usuario. La estructura básica del AWT se
basa en Componentes y Contenedores. Las clases utilizadas de esta biblioteca, en la
implementación de la herramienta son:
o Color
o Graphics
o Dimension
o Toolkit
o Event
o Component
o Canvas
72
� IO: Es el acrónimo de Input y Output (Entrada y Salida). Es el paquete que contiene las
clases necesarias para el manejo los flujos de entrada y salida. Las clases utilizadas de esta
biblioteca, en la implementación de la herramienta son:
o File
o PrintWriter
o BufferedReader
o FileReader
o FileWriter
o PrintWriter
� UTIL: Contiene otras clases útiles que ayudan al programador. Las clases utilizadas de esta
biblioteca, en la implementación de la herramienta son:
o ArrayList o List
� SWING: Es una extensión del AWT, que proporciona un conjunto completo de
componentes dependientes del sistema operativo. Las clases utilizadas de esta biblioteca, en
la implementación de la herramienta son:
o DefaultCellEditor
o JComboBox
o JTable
o ChangeEvent
o CellEditorListener
o JButton
3.5.2. REUTILIZACIÓN DE CÓDIGO
La reutilización de código consistió en la transformación de los Tipos de Datos Abstractos (ADT11)
codificados en el lenguaje C a codificación de Clases Java. En este proceso se encapsularon los
elementos de las estructuras y las funciones se convirtieron en métodos, eliminando el uso de
memoria dinámica y reduciendo el paso de parámetros en la implementación de los métodos.
A continuación se muestra el código fuente de un ejemplo de ADT llamado STDATO usado en la
herramienta anterior para almacenar las propiedades físicas y de ubicación de un elemento del
diagrama de flujo:
/*Definición de la estructura*/
11 Acrónimo del inglés Abstract Data Type
73
struct stDato{ GdkRectangle fig; //Área que define el tamaño de la figura GdkRectangle amb; // Área sobre la cual no puede pasar una flecha GdkPoint centro; //centro de la figura gint tipo; //tipo de estructura gchar *codigo; //Código asociado al dato gint stx; //sintaxis correcta 1, sintaxis incorrecta gchar *num; //número de elemento en el diagrama }; typedef struct stDato STDATO; /*Función para crear un nuevo Dato*/ STDATO nuevoDato(GdkRectangle f, gint t, gchar *c) { STDATO dat; dat.fig = f; dat.amb = f; dat.centro.x = f.x + (f.width/2); dat.centro.y = f.y + (f.height/2); dat.tipo = t; dat.codigo = g_strdup(c); dat.stx = 1; dat.num = NULL; return dat; } /*Función que identifica si el elemento recibido es una flecha*/ gboolean esflecha(const STDATO *pdat) { switch(pdat->tipo){
case FLECHANORM: case FLECHACIZQ: case FLECHACDER: case FLECHACUNI: case FLECHANSEL: case FLECHAPARA: case FLECHAMIEN: case FLECHAHAST: case FLECHASCIC: case FLECHARETH: return TRUE;
} return FALSE; } /*Función que identifica si el elemento recibido es una flecha insertable*/ gboolean esflechains(const STDATO *pdat) { switch(pdat->tipo){
case FLECHANORM: case FLECHACUNI: case FLECHACIZQ: case FLECHACDER: case FLECHASCIC: case FLECHAHAST: return TRUE;
} return FALSE;
74
} /*Función que identifica si el elemento recibido es una estructura del diagrama de flujo*/ gboolean eselementod(const STDATO *pdat) { switch(pdat->tipo){
case LEER: case CALCULAR: case ESCRIBIR: case CONDICION: case PARA: case CONDPARA: case INCDECPARA: case MIENTRAS: case HASTA: return TRUE;
} return FALSE; } /*Función que ajusta la figura al texto recibido*/ gboolean ajustarFig(STDATO *pdat, gchar *c, PangoLayout *layout) { gint w, h; if(c == NULL && pdat->codigo == NULL) return FALSE; if(c != NULL && pdat->codigo != NULL) g_free(pdat->codigo); if(c != NULL) pdat->codigo = g_strdup(c); pango_layout_set_text(layout,pdat->codigo, -1); pango_layout_get_size(layout,&w,&h); w = (w/PANGO_SCALE)+10; h = (h/PANGO_SCALE)+10; if(pdat->tipo == CONDICION || pdat->tipo == CONDPARA || pdat->tipo == MIENTRAS
|| pdat->tipo == HASTA) h+=10; pdat->fig.x = pdat->centro.x - (w/2); pdat->fig.width = w; pdat->fig.height = h; pdat->amb = pdat->fig; pdat->centro.y = pdat->fig.y + (h/2); return TRUE; } /*Función que ajusta el centro del Dato recibido*/ void ajustarCentro(STDATO *pdat) { pdat->centro.x = pdat->fig.x + (pdat->fig.width/2); pdat->centro.y = pdat->fig.y + (pdat->fig.height/2); }
La traducción implementada en código java es la que se muestra a continuación, nótese que tanto
como el código y la estructura son muy similares, por lo tanto es fácil notar los cambios realizados:
public class Dato { Rectangulo fig; //Área que define el tamaño de la figura
75
Rectangulo amb; //Área sobre la cual no puede pasar una flecha int centro_x; //Centro de la figura int centro_y; //Centro de la figura int tipo; //Tipo de dato String codigo; //Código asociado al dato boolean stx; //Sintaxis correcta 1, sintaxis incorrecta String num; //Número de elemento en el diagrama CTexto ctext;
/*Contructor de la clase */ public Dato(Rectangulo f, int tipo, String codigo) { inicializa(f); this.tipo = tipo; this.codigo = codigo; this.centro_x= this.fig.x+(this.fig.ancho/2); this.centro_y= this.fig.y+(this.fig.alto/2); this.stx=true; this.num=""; ctext=null; }
/*Método que inicializa el Rectangulo*/ private void inicializa(Rectangulo f) { this.fig=new Rectangulo(f.x,f.y,f.ancho,f.alto); amb=new Rectangulo(f.x,f.y,f.ancho,f.alto); } /*Método verifica si el Dato actual es Flecha*/ boolean esFlecha(){ switch(this.tipo){ case FLECHANORM: case FLECHACIZQ: case FLECHACDER: case FLECHACUNI: case FLECHANSEL: case FLECHAPARA: case FLECHAMIEN: case FLECHAHAST: case FLECHASCIC: case FLECHARETH: return true; } return false; } /*Método verifica si el Dato actual es Flecha insertable*/ boolean esFlechaIns(){ switch(this.tipo){ case FLECHANORM: case FLECHACUNI: case FLECHACIZQ: case FLECHACDER: case FLECHASCIC: case FLECHAHAST: return true; } return false; }
76
/*Método verifica si el elemento actual es una Estructura del diagrama de flujo*/ boolean esElementoD(){ switch(this.tipo){ case LEER: case CALCULAR: case ESCRIBIR: case CONDICION: case PARA: case CONDPARA: case INCDECPARA: case MIENTRAS: case HASTA: return true; } return false; } /*Método que ajusta el centro de la figura*/ void ajustarCentro(){ this.centro_x = this.fig.x + (this.fig.ancho/2); this.centro_y = this.fig.y + (this.fig.alto/2); } /*Método que ajusta la figura con respecto al código de la figura actual*/ boolean ajustarFig(Graphics g){ int w=0, h=0; ctext = new CTexto(this.codigo,g); w = ctext.ancho+10; h = ctext.alto+10; if(this.tipo == CONDICION || this.tipo == CONDPARA || this.tipo == MIENTRAS || this.tipo == HASTA) h+=10; this.fig.x = this.centro_x - (w/2); this.fig.ancho = w; this.fig.alto = h; this.amb.Copiar(this.fig); this.centro_y = this.fig.y + (h/2); return true; }
}
Sin embargo, el prototipo inicial utiliza librerías propias del proyecto Gnome (The GNOME12
Projec) tales como GTK13, GDK14 y Pango, evidentemente dichas librerías no están disponibles
para Java, así que se buscaron clases equivalentes en el repertorio de bibliotecas Java. El problema
12 Acrónimo del inglés GNU Network Object Model Environment.
13 Acrónimo del inglés GOBI Tool Kit
14 Acrónimo del inglés GIMP DrawingKit
77
es que no siempre se encontraron los equivalentes y como consecuencia, se tuvo la necesidad de
crear nuevas clases para que realizar las mismas funciones.
Un ejemplo muy claro de un ADT usado en la herramienta anterior es el llamado Pango, que sirve
para dar color y formato al texto desplegado en un área gráfica. Al no encontrar un equivalente en
java, fue necesario implementar una nueva clase que proporcionará la funcionalidad requerida.
Dicha clase fue nombrada CTexto y su código se presenta a continuación:
public class CTexto { List<String> Texto; int alto; int ancho; Graphics g; public CTexto(String Cadena,Graphics g){ this.g=g; Texto=new ArrayList(); analizacadena(Cadena); calcAltoAncho(g); } public void Trazar(int x, int y,boolean stx, Color color){ g.setColor(color); int a=g.getFontMetrics().getHeight(); for(int i=0;i<Texto.size();i++){ if(!stx) g.setColor(Color.red); g.drawString(Texto.get(i), x, y+a); y=y+a; } } public void Trazar(int x, int y,boolean stx){ int a=g.getFontMetrics().getHeight(); for(int i=0;i<Texto.size();i++){ g.setColor(Color.BLACK); if(!stx) g.setColor(Color.red); g.drawString(Texto.get(i), x, y+a); y=y+a; } } private void calcAltoAncho(){ int i=0; alto = g.getFontMetrics().getHeight()*(Texto.size()); ancho= g.getFontMetrics().stringWidth(Texto.get(i)); for(i=1;i<Texto.size();i++){ if(ancho < g.getFontMetrics().stringWidth(Texto.get(i)))
78
ancho= g.getFontMetrics().stringWidth(Texto.get(i)); } } private void calcAltoAncho(Graphics g){ int i=0; alto = g.getFontMetrics().getHeight()*(Texto.size()); ancho= g.getFontMetrics().stringWidth(Texto.get(i)); for(i=1;i<Texto.size();i++){ if(ancho < g.getFontMetrics().stringWidth(Texto.get(i))) ancho= g.getFontMetrics().stringWidth(Texto.get(i)); } } private void analizacadena(String rotulo) { String renglon=""; for(int i=0;i<rotulo.length();i++){ switch (rotulo.charAt(i)){ case '\n': Texto.add(renglon); renglon=""; break; case '\t': renglon=renglon+" "; break; default: renglon=renglon+rotulo.charAt(i); break; } } Texto.add(renglon); } }
3.5.3. DIAGRAMA DE DESPLIEGUE
En el diagrama de despliegue mostrado en la Figura 37 se puede observar que el SAAA es una
aplicación que se ejecuta en una computadora personal (ya sea portátil o de escritorio), por lo tanto
aun cuando está implementado en java, no se trata de una aplicación que se ejecute en línea. Cabe
aclarar que dicha computadora debe tener instalada la máquina virtual de java para que la aplicación
se ejecute sin problemas.
79
Figura 37 Diagrama de despliegue
3.6. WORKFLOW DE PRUEBAS
Las pruebas realizadas en este workflow, se basan en lo establecido por (Schach, 2005) en lo
referente a las pruebas basadas en la ejecución. Se preparó un conjunto de casos de prueba con base
en las especificaciones de software, por lo tanto se trata de casos de prueba de caja negra.
3.6.1. PRUEBA DE UTILIDAD
Esta prueba consistió en ejecutar y explorar el SAAA para verificar que la herramienta se ejecuta
sin ningún problema y cumple con los objetivos prometidos en el presente documento. Como
resultado de la prueba de utilidad se comprobó que:
� Es un software que satisface la necesidad de contar con una herramienta para enseñar y/o
aprender algoritmos.
� Es un software que satisface la necesidad de implementar una heurística de resolución de
problemas.
� La herramienta cuenta con una interfaz amigable y como conclusión se cuenta con una
herramienta de fácil manejo para cualquiera de los usuarios.
80
� La herramienta contiene funciones muy útiles entre ellos, la traducción del diagrama de
flujo a lenguajes de alto nivel y la ejecución del diagrama de flujo para realizar pruebas a la
solución diseñada.
� Es un software rentable porque además de no tener costo alguno para el usuario final, es
una herramienta completa y mucha utilidad para cuestiones didácticas.
3.6.2. PRUEBA DE FIABILIDAD
Para esta prueba se desarrollaron diversas soluciones a distintos tipos de problemas, utilizando
todos los tipos de datos, de estructuras y de opciones que ofrece la herramienta (el caso de ejemplo
de la sección 4.3 es un ejemplo de las soluciones creadas para esta prueba). Se abrieron apropósito
archivos corruptos y archivos que no pertenecen al formato. Y como resultado se concluyó que el
SAAA es fiable porque:
� Los fallos que tiene no son frecuentes ni graves.
� Los fallos solo afectan a la solución actual que no se ha guardado.
� No abre archivos que no cumplan con la gramática que se especifica al momento de
guardar.
3.6.3. PRUEBA DE SOLIDEZ O ROBUSTEZ
Para esta prueba de manera intencional se introdujeron valores erróneos, se dejaron en blanco
algunas secciones, se ignoraron algunas reglas de sintaxis, se intentó insertar elementos en áreas
inválidas y también se verificaron algunos flujos alternos de los casos de uso. Teniendo como
conclusión que la herramienta es robusta porque:
� No toma en cuenta respuestas de un solo carácter, en la sección de preguntas de la etapa
Analizar.
81
� Advierte al usuario cuando existen elementos que no se le han asignado una o varias
propiedades en la etapa Planear.
� Advierte al usuario cuando se realiza la asignación de un valor inicial que no concuerde con
el tipo de dato del elemento.
� Evita la adición de una estructura de control en un área inválida en la etapa Diseñar.
� Evita la edición de las estructuras Iniciar, Inicializar y Finalizar.
� Indica al usuario de errores sintácticos y semánticos al momento de compilar el diagrama de
flujo.
� Evita la ejecución y traducción del diagrama de flujo con errores sintácticos y semánticos.
� Evita datos de entrada incorrectos en estructuras de control de tipo Leer al momento de
probar la solución.
3.6.4. PRUEBA DE DESEMPEÑO
Para esta prueba se observaron los tiempos de respuesta del software y se ejecutaron las pruebas de
algunas soluciones creadas, llegando a la conclusión que el desempeño no es algo crítico para el
SAAA porque no es una herramienta que debe recibir datos o generar respuestas en tiempo real. Sin
embargo, se ve afectado al momento de probar una estructura cíclica con un número de repeticiones
demasiado grande (arriba de 50 iteraciones) ya que puede resultar tedioso para el usuario concluir la
corrida de escritorio.
3.6.5. PRUEBA DE CORRECCIÓN
Esta prueba consistió en seguir paso a paso los casos de uso de la sección 3.2.2 para observar la
respuesta del sistema y comprobar que correspondían adecuadamente. También consistió en las
cuatro pruebas realizadas anteriormente por el autor del presente documento junto con los autores
82
del prototipo ABEA y como resultado de esta prueba se detectaron y corrigieron los siguientes
errores:
� En la etapa Planear, la herramienta no acepta nombres de identificadores con el carácter
guion bajo.
� Si en la etapa Planear inicializaba un elemento de tipo real con un valor entero, al pasar a la
etapa Diseñar en la estructura de control de tipo inicializar, no se corregía el dato a real.
� En la etapa Diseñar, después de insertar un elemento al diagrama de flujo, la herramienta
permitía la inserción de una estructura de control al diagrama de flujo, sin antes haber
señalado la ubicación.
� En la etapa Diseñar, la herramienta permitía la modificación de variables declaradas como
constantes.
� En la etapa Diseñar al momento de traducir una estructura de control de tipo Calcular que
separa las operaciones con un salto de línea, cuando la herramienta traducía a código C y/o
Pseudocódigo, no separaba las operaciones con un punto y coma.
� En la etapa Probar, al ir avanzando con la ejecución del diagrama de flujo, las barras de
desplazamiento no se movían para mostrar la flecha que indica el elemento a ejecutar.
� En la etapa Proba cuando se ejecutaba una estructura de control de tipo Leer, la ejecución
entraba a un ciclo infinito que terminaba solo cuando el usuario insertaba datos numéricos
positivos, es decir, no se aceptaban números negativos.
CCAAPPII TTUULL OO 44
RESULTADOS
4.1. Resultados comparativos con software similares
4.2. Resultados comparativos con la versión anterior.
4.3. Caso de ejemplo
85
4.1. RESULTADOS COMPARATIVOS CON SOFTWARE SIMILARES
Dada la similitud de la herramienta desarrollada en el presente trabajo con las descritas en el estado
del arte (Sección 1.3), se realizó una serie de comparaciones de las principales características del
SAAA con SICAS versión 2.0, RAPTOR versión 3.8.0.0001 y FreeDFD versión 1.1 para destacar
las ventajas del SAAA con herramientas que también buscan servir como apoyo didáctico en la
enseñanza-aprendizaje de algoritmos. El resultado de las comparaciones se muestra en la Tabla 7.
Cabe mencionar que el RAPTOR y DFD son herramientas que se encuentran con facilidad en el
internet y por lo tanto son muy populares en el ámbito didáctico de nivel superior.
Tabla 7 Comparativa con otras herramientas similares
Características SICAS RAPTOR DFD SAAA
Heurística de resolución de problemas
Soporte para la fase de Analizar el problema
Soporte para la fase de Planear la solución
Soporte para los tipos de datos enteros
Soporte para los tipos de datos reales
Soporte para los tipos de datos cadenas
Soporte para los tipos de datos boleanos
Soporte para la fase el diseño del diagrama de flujo
Ajuste automático en el diseño del diagrama de flujo
Edición de múltiples líneas en la etapa Diseñar
Lectura de múltiples variables en un mismo elemento
Escritura de múltiples variables en un mismo elemento
Notación formal para la estructura secuencial LEER
Notación formal para la estructura secuencial CALCULAR
Notación formal para la estructura secuencial ESCRIBIR
86
Notación formal para el ciclo PARA
Notación formal para el ciclo MIENTRAS
Notación formal para el ciclo HASTA
Soporte para funciones y procedimientos
Soporte para funciones de librería
Soporte para arreglos y matrices
Soporte para ciclo PARA
Soporte para ciclo MIENTRAS
Soporte para ciclo HASTA
Ajuste correcto en el anidamiento de estructuras condicionales
Ajuste correcto en el anidamiento de estructuras cíclicas
Traducción a código en lenguaje de alto nivel
Intérprete del diagrama de flujo
Corrida de escritorio o traza del diagrama completa
Funcionalidades estándar(Nuevo, Abrir, Guardar, Guardar como)
Suma de características implementadas 12 16 17 27
Es necesario aclarar que las comparaciones hechas a la herramienta SICAS no fueron realizadas con
la ejecución del software al no encontrarse disponible en línea, por lo tanto, los resultados de la
Tabla 7 fueron tomadas del artículo citado en el estado del arte del presente documento. Los
renglones de la tabla que se dejaron en blanco son comparaciones que solo se puede definir con el
software.
La herramienta SICAS solo cumple con 12 de las características mostradas en la Tabla 7, pero de
las 30 características, la herramienta RAPTOR cumple con 16, la herramienta llamada DFD cumple
con 17, y el SAAA cumple con 27.
87
4.2. RESULTADOS COMPARATIVOS CON LA VERSIÓN ANTERIOR
Dado que el SAAA es una versión mejorada del ABEA. En la Tabla 8 se muestra las mejoras del
software actual (SAAA), respecto a la herramienta ABEA.
Tabla 8 Mejoras del software actual respecto a la herramienta ABEA
Características ABEA SAAA
Cuadros de diálogo de ayuda en la etapa de análisis
Cuadros de diálogo de ayuda en la etapa de diseño
Soporte para la asignación de valores iniciales
Copiar cualquier tipo de elementos
Pegar cualquier tipo de elementos
Cortar cualquier tipo de elementos
Traducción a código en lenguaje de alto nivel
Uso de colores para facilitar la comprensión en la etapa de Diseño del diagrama de flujo
Uso de color en las flechas válidas para la inserción de nuevos elementos
Visualizar la evaluación de las condiciones durante la corrida de escritorio
Soporte para funciones de librería
Habilitar y deshabilitar de forma automática los botones de edición en el diagrama de flujo
Adicionalmente a las características listadas en la Tabla 8, se tienen las siguientes mejoras añadidas
al software:
• Al tener una implementación utilizando Java, ahora la herramienta es multiplataforma
gracias a que se ejecuta sobre la máquina virtual de Java.
• La notificación e interacción con los mensajes de error en la compilación durante la fase de
diseño ha sido mejorado.
88
• Corrección de algunos errores gramaticales en la fase de diseño.
• Simplificación de la interfaz de usuario en la corrida de escritorio.
• En la etapa Probar las barras de desplazamiento se mueven automáticamente, dejando a la
vista la siguiente estructura a ejecutar.
4.3. CASO DE EJEMPLO
Antes de comenzar con nuestro caso de ejemplo, es necesario revisar el manual de usuario ubicado
en el Apéndice C del presente documento, para conocer a detalle el uso y la estructura de la
herramienta.
A continuación se muestra, a manera de ejemplo, la solución paso a paso de un problema
empleando la herramienta y siguiendo el diagrama de estados mostrado en la Figura 23 de la
Sección 3.3.2 (Para ver este ejemplo con mayor detalle, ver el manual de usuario).
Se parte del siguiente enunciado del problema:
4.3.1. ETAPA ANALIZAR
Se comienza en la pestaña Analizar de la herramienta que se muestra en la Figura 38.
El primer paso es escribir el enunciado inicial del problema, que por lo general es el mismo
enunciado del problema planteado.
Enunciado inicial: Se desea un algoritmo que calcule la hipotenusa de un triángulo rectángulo.
Problema: Se desea un algoritmo que calcule la hipotenusa de un triángulo rectángulo.
89
Figura 38 Pestaña Analizar
Después se responden las ocho preguntas que ayudan al alumno a analizar el enunciado inicial del problema.
1. ¿Cuáles son los datos iniciales del problema? R= El enunciado no proporciona
valores iniciales.
2. ¿Qué es necesario preguntar para completar los datos iniciales? R= Se requiere
preguntar por el valor de los catetos a y b
3. ¿De dónde se tomará los datos iniciales? R= El problema no lo dice.
4. ¿Cuáles son los supuestos? R= 1. Se asume que se cuenta con teclado para introducir
datos 2. Se asume que se tiene una pantalla para mostrar los resultados 3. Tanto el
valor de los catetos como el de la hipotenusa pueden ser enteros o reales positivos 4. El
mensaje a mostrar como resultado será: "el valor de la hipotenusa es: ", seguido de la
hipotenusa
5. ¿Cuál es la incógnita? R= La hipotenusa
6. ¿Qué es lo que se quiere resolver o calcular? R= 1. Calcular la hipotenusa mediante
la fórmula c=√ (a²+b²), donde c es la hipotenusa y a, b los catetos. 2. Además se
necesita calcular a² y b², lo anterior se puede calcular multiplicando a*a y b*b
respectivamente.
90
7. ¿Qué información ha de presentarse como resultado? R= Según los supuestos "el
valor de la hipotenusa es: ", seguido del valor de la hipotenusa
8. ¿A través de qué forma se presentarán los resultados? R= Según los supuestos, a
pantalla.
Por último para esta etapa, se edita el enunciado final del problema, con toda la información que
nos proporciona las respuestas anteriores.
Enunciado final: Se desea un algoritmo que calcule la hipotenusa de un triángulo
rectángulo. El algoritmo deberá solicitar al usuario que introduzca los valores de los
catetos a y b para calcular el cuadrado de cada uno de ellos y después aplicar la fórmula
c=√ (a²+b²), siendo c la hipotenusa. El valor de la hipotenusa se deberá mostrar a pantalla
después del mensaje "el valor de la hipotenusa es: " seguido del valor calculado.
Al final la información vertida en la herramienta queda como se presenta en la Figura 39. Para
observar con mayor detalle los pasos para rellenar la pestaña Analizar de este ejemplo, ver el
apéndice C del presente documento.
Figura 39 Pestaña Analizar para el caso ejemplo (con información)
91
4.3.2. ETAPA PLANEAR
Una vez concluida la etapa de Analizar se da un clic en la pestaña Planear mostrándose la pestaña
correspondiente, ver Figura 40.
Figura 40 Pestaña Planear
Con el botón Agregar, se añaden los elementos y se le asignan los roles que se muestran en la Tabla
9.
Tabla 9 Tabla para la lista de elementos
Nombre del elemento Entrada Salida Auxiliar
El cateto a �
El cateto b �
La hipotenusa �
92
Al añadir los elementos a la Lista de elementos, automáticamente se agregan también los mismos
elementos a la Lista de asignación de identificadores con el objetivo de editar las siguientes
propiedades del elemento:
• Tipo de dato
• Identificador
• Tipo de identificador
• Valor inicial
Por lo tanto se editarán los elementos de la Lista de asignación de identificadores con las
propiedades que se muestran en la Tabla 10.
Tabla 10 Propiedades de la Lista de asignación de identificadores
Elemento Tipo de dato Identificador Tipo de identificador Valor inicial
El cateto a Real a Variable null
El cateto b Real b Variable null
La hipotenusa Real c Variable null
Al finalizar tenemos que la información vertida en la herramienta queda como se muestra en la
Figura 41.
Figura 41 Pestaña Planear para el caso ejemplo (con información)
93
4.3.3. ETAPA DISEÑAR
En esta etapa, se diseñará el diagrama de flujo que resuelve el problema planteado. Al darle clic en
la pestaña diseñar, se mostrará su contenido tal como se muestra en la Figura 42.
Por omisión, se genera un diagrama de flujo inicial como se muestra en la Figura 42. Dicho
diagrama por omisión contiene tres estructuras secuenciales de tipo: Iniciar, finalizar e Inicializar.
Donde el elemento Inicializar contiene la inicialización al valor inicial (si tiene null, se inicializa
por omisión con 0 para los enteros, 0.0 para los reales y “” para las cadenas) de cada uno de los
identificadores de todos los elementos añadidos a la Lista de elementos en la etapa anterior (Etapa
Planear).
Figura 42 Pestaña Diseñar
A continuación se añaden estructuras de control necesarias para resolver el problema de la mejor
manera posible. Para este caso de ejemplo se diseña un diagrama de flujo como el que se muestra
Figura 43, donde fueron añadidas únicamente estructuras de secuenciales de tipo: Leer, Calcular y
Escribir.
94
También se utiliza la función de librería SQRT(X)15 que sirve para realizar el cálculo de la raíz
cuadrada de X.
Al terminar de diseñar el diagrama de flujo, es necesario que se compile el diagrama, para verificar
que no existan errores. Cuando el resultado de la compilación sea satisfactorio, se puede pasar a la
siguiente etapa (Etapa Probar).
Figura 43 Diagrama de flujo que calcula la hipotenusa
4.3.3.1. TRADUCIR A…
Al terminar de diseñar el diagrama de flujo se puede traducir a Pseudocódigo o al lenguaje C, pero
antes se debe compilar para verificar que no existan errores sintácticos o semánticos.
Una vez que el resultado de la compilación sea satisfactoria, se da clic en el botón Traducir a…
(Ubicado en la parte superior del área de dibujo de la pestaña Diseñar ver Figura 42). Aparece un
cuadro de diálogo (Ver Apéndice C, Sección 4.3.4) que muestra las opciones que la herramienta
15 Ver la sección Funciones de Librería del Apéndice C.
95
ofrece y de las cuales se puede seleccionar una o las dos, como se desee. Ya elegida la opción (o las
opciones) se da clic en el botón Aceptar e inmediatamente se tiene disponibles los archivos con
extensión .txt para el pseudocódigo y .c para el lenguaje C.
A continuación se muestra el resultado de las traducciones (del diagrama de flujo mostrado en la
Figura 43) que ofrece la herramienta.
TRADUCCIÓN A PSEUDOCÓDIGO
TRADUCCIÓN A LENGUAJE C
#include <stdio.h> #include <stdlib.h> #include <math.h> int main() { float a= 0.0; float b= 0.0; float c= 0.0; printf("Introduzca el valor del cateto a: \n"); scanf(" %f", &a); printf("Introduzca el valor del cateto b: \n"); scanf(" %f", &b); c=sqrt((a*a)+(b*b)); printf("El valor de la hipotenusa es: %f\n",c); getch(); return 0; }
1.- Iniciar 2.- INICIALIZAR a=0.0 3.- INICIALIZAR b=0.0 4.- INICIALIZAR c=0.0 5.- ESCRIBIR "Introduzca el valor del cateto a: " 6.- LEER a 7.- ESCRIBIR "Introduzca el valor del cateto b: " 8.- LEER b 9.- c=SQRT((a*a)+(b*b)) 10.- ESCRIBIR "El valor de la hipotenusa es: ", c 11.- Finalizar
96
4.3.4. ETAPA PROBAR
Ya diseñada la solución tentativa al problema, es necesario verificar que el diagrama de flujo se
ejecute de la manera que se desea. Para esto es necesario pasar a la siguiente etapa llamada Probar.
Al darle clic a la pestaña Probar mostrará el contenido de dicha pestaña tal y como se muestra en la
Figura 44.
Como se observa en la Figura 44 el diagrama de flujo creado en la etapa anterior (Etapa Diseñar), se
encuentra en la parte izquierda de la ésta pestaña pero la diferencia es que ahora ya no es editable y
que todos sus elementos han sido enumerados de madera ascendente para la identificación univoca
de cada elemento a ejecutar.
Para comenzar la ejecución del diagrama de flujo, basta únicamente un clic en el botón Inicio
ubicado en la parte inferior, el nombre de este botón cambia a siguiente y es así como con un solo
clic se comienza la ejecución.
Figura 44 Pestaña Probar
Para continuar con la prueba y observar cómo se ejecuta cada una de las estructuras del diagrama de
flujo, basta con dar clics en el botón siguiente (mismo botón) hasta que se ejecute la estructura
Finalizar del diagrama de flujo, quedando un resultado como se muestra en la Figura 45.
97
Figura 45 Ejecución terminada del diagrama de flujo
CCAAPPII TTUULL OO 55
CONCLUSIONES Y TRABAJO FUTURO
5.1. Conclusiones
5.2. Trabajo futuro
101
5.1. CONCLUSIONES
Con base en la metodología empleada en el presente trabajo de tesis, se ha logrado obtener una
herramienta que cumple con todos los requisitos planteados en los objetivos de este documento.
Al aplicar la heurística de Polya los alumnos se estarán introduciendo indirectamente a la ingeniería
de software (ver Sección 2.2) ya que la fase de definición se implementa con la etapa Analizar de la
herramienta al centrarse solo en el Qué es lo que se desea resolver. La fase de desarrollo equivale a
las etapas de Planear y Diseñar pues se centran principalmente en el Cómo se resolverá el problema.
Y en la fase de implementación de la ingeniería de software empata con la etapa Probar de la
herramienta enfocándose principalmente en la realización de cambios correctivos, adaptativos,
preventivos y mejoras.
Por otro lado, la herramienta desarrollada encaja perfectamente con el esquema de aprendizaje
propuesto en el método de enseñanza de algoritmos centrado en 2 dimensiones ya que está diseñada
para ayudar a mejorar la capacidad de resolver problemas y de abstracción del alumno.
Al transformar el código estructurado para el sistema operativo Linux del prototipo inicial, al
código orientado a objetos de la herramienta final, se buscaron clases equivalentes en el repertorio
de bibliotecas Java. Sin embargo, no siempre se encontraron los equivalentes y como consecuencia,
se tuvo la necesidad de crear nuevas clases para que realizar las mismas funciones.
Con base en las pruebas hechas en el sección 3.6, se concluye que la herramienta es un software útil
para los usuarios gracias a la metodología para resolver problemas que implementa en su interfaz,
que es una herramienta fiable al no tener errores frecuentes ni graves, que es un software robusto al
impedir en su mayoría datos de entrada erróneos y por último que es una herramienta con un buen
desempeño en su tiempo de respuesta.
Además, con base a los resultados del Capítulo 4 se concluye que el SAAA aventaja a varias
herramientas con propósitos similares (incluyendo al prototipo anterior) al implementar
características importantes que ayudan al usuario en el aprendizaje o enseñanza de algoritmos
siguiendo una metodología de resolución de problemas. Y aunque el software no implemente aún
algunas características (por ejemplo el soporte de variables de tipo arreglo) que los demás sí, estas
características forman parte del trabajo futuro de la presente tesis.
102
Cabe mencionar que los conocimientos reforzados en el desarrollo del presente proyecto de tesis
son principalmente relacionados a los temas de ingeniería de software, específicamente en
reingeniería, el Proceso Unificado y UML. Otros temas también reforzados son los referentes al
área de compiladores e intérpretes, específicamente en gramáticas libres de contexto, aplicación de
la técnica de análisis sintáctico por descenso recursivo y empleo de validaciones semánticas. De
igual manera se reforzaron conceptos de programación orientado a objetos al desarrollar la
herramienta en el lenguaje Java. Por otro lado, el conocimiento adquirido está relacionado con el
tema de la heurística de resolución de problemas de Polya.
5.2. TRABAJO FUTURO
Aunque el software para la asistencia en el aprendizaje de algoritmos es una herramienta que ya
cumple con el objetivo planteado en la presente tesis, se pretende continuar trabajando en ella para
añadirle nuevas características como:
• La opción de imprimir la solución actual, incluyendo todas las etapas de la herramienta.
• Soporte para variables de tipo arreglo unidimensional y bidimensional, además de datos y
variables de tipo lógico, así como tipos de datos definidos por el usuario.
• Un botón de zoom en la etapa Diseñar, para que el usuario pueda visualizar completamente
diagramas de flujo extensos.
• Un botón para exportar los diagramas de flujo a archivos tipo imagen como JPG, BMP, etc.
• La opción de agregar funciones y procedimientos definidas por el usuario al diagrama de
flujo, desde la paleta de estructuras.
• La opción de agregar comentarios al diagrama de flujo, desde la paleta de estructuras.
• La posibilidad de deshacer acciones en la edición del diagrama de flujo.
103
• Aumentar la lista de opciones para traducir el diagrama de flujo a otros lenguajes de alto
nivel como Fortran, Pascal, etc.
• Resaltado tipográfico en el código de las estructuras de control del diagrama de flujo.
• Poder ejecutar de manera continua la corrida de escritorio en la etapa Probar.
• Tener la posibilidad de deshacer un paso de ejecución retornando al paso anterior durante la
corrida de escritorio.
• La posibilidad de pausar o parar una corrida de escritorio de ejecución continua.
RREEFFEERREENNCCII AASS
105
BIBLIOGRAFÍA
freedfd. (Octubre de 2008). Recuperado el 1 de Marzo de 2012, de http://code.google.com/p/freedfd
Aho, A. V., Sethi, R., Hill, M., & Ullman, J. D. (1990). Compiladores, principios, técnicas y
herramientas. Pearson Educación.
Arellano Pimentel, J. J., & Nieva García, O. S. (2010). ABEA, Herramientas de apoyo en la
enseñanza de algoritmos y habilidades de programación. VI Semana Nacional de Ingeniería
Electrónica, (págs. 193-202). Huajuapan de León, Oaxaca.
Cardenas Valera, F. A., Castillo Izquierdo, N. E., & Daza Castillo, E. d. (1998). Editor e intérprete
de algoritmos representados en diagramas de flujo. Informatica Educativa UNIANDES -
LIDIE, 101-106.
Charlise, M. C., Willson, T. A., & al., e. (2004). RAPTOR: introducing programming to non-majors
with flowcharts. Journal for Computing Sciences in Colleges, 52-60.
Cueva Lovelle, J. M. (1998). Cuadernos Didácticos. Conceptos básicos de procesadores de
lenguaje. Oviedo, España: SERVITEC.
Galvez Rojas, S., & Mora Mata, M. A. (2005). Java a tope: Traductores y compiladores con
Lex/Yacc, JFlex/Cup y JavaCC. Universidad Málaga.
Galvis Panqueva, A. H. (1988). Ambientes de Enseñanza-Aprendizaje Enriquecidos con
Computador. Boletín de Informática Educativa, (págs. 117-14).
Larman, C. (2004). UML y patrones: una introducción al análisis y diseño orientado a objetos y al
proceso unificado. Madrid, España: Pearson Educación.
Louden, K. C. (2004). Construccion de compiladores. Principios y práctica. Mexico: Ediciones
Paranninfo.
106
Marcelino, M., & Gomes, A. (2004). Using a computer-based interactive system for the
development of basic algorithmic and programing skills. International Conference on
Computer Systems and Technologies, (págs. 1-6). New York, USA.
NetBeans . (s.f.). Recuperado el 17 de Febrero de 2012, de http://netbeans.org/index_es.html
Nieva García, O. S., & Arellano Pimentel, J. J. (2009). Método de enseñanza centrado en 2
dimensiones. 4to Simposio Internacional en Sistemas Telemáticos y Organizaciones
Inteligentes (págs. 881-897). Xalapa, Veracruz: Fesi.
Oliver, R. (1999). Exploring strategies for on-line teaching and learning. Distance Education, 240-
254.
Oracle. (s.f.). Java y Tú. Recuperado el 17 de Febrero de 2012, de http://java.com/es/
Polya, G. (2005). Cómo plantear y resolver problemas. Mexico: Trillas.
Pressman, R. S. (2002). Ingeniería del software. Un enfoque practico. Madrid: Mc-Graw Hill
Interamericana de España.
Quintas, A. F. (2008). JAVA 2 Manual de usuario y Tutorial. Mexico: Alfaomega Ra-Ma.
RAPTOR. Flowchar imterpreter. (s.f.). Recuperado el 3 de Diciembre de 2010, de
http://raptor.martincarlisle.com/
Schach, S. R. (2005). Análisis y diseño Orientado a objetos con UML y el proceso unificado.
Mexico: McGraw-Hill Interamericana.
The GNOME Projec. (s.f.). Recuperado el 29 de Febrero de 2012, de http://www.gnome.org
AAPPÉÉNNDDII CCEESS
CONTENIDO APÉNDICES
A. Casos de uso
B. Diagrama de clases
C. Manual de usuario
109
A. CASOS DE USO
Caso de uso: Crear nuevo
Descripción general: Crea una nueva solución sin nombre dejando limpias las cuatro etapas de resolución de problemas.
Flujo básico:
Acción del actor Respuesta del sistema
1. Presiona el botón Nuevo o elige la opción Nuevo del menú Archivo de la Ventana principal.
2. Limpia todas las etapas de la solución.
3. La barra de título de la aplicación queda con el nombre por omisión (<Sin Nombre>.abea) y el nombre de la aplicación.
Precondiciones:
1. La aplicación se está ejecutando.
Postcondiciones:
1. Todos los campos de edición y captura de datos quedan limpios y se asigna el nombre por omisión a la solución.
Flujos alternos:
1. Si existe una solución abierta y se desea guardar los cambios, se ejecuta el caso de uso Guardar solución previo a la limpieza de las pantallas.
Caso de uso: Guardar
Descripción general: Guarda los cambios a la solución actual de la información relacionada a las tres primeras etapas.
Flujo básico:
110
Acción del actor Respuesta del sistema
1. Presiona el botón Guardar en la barra de herramientas o elige la opción Guardar del Menú Archivo de la Ventana principal.
2. Guarda la información de las tres primeras etapas
de la herramienta en un formato especial con el mismo nombre de la solución actual.
Precondiciones: 1. Que la solución actual no tenga el nombre por omisión. 2. Que se haya guardado previamente la solución actual.
Postcondiciones: 1. Se reemplaza el archivo existente con la información de las tres primeras etapas de la solución.
Flujos alternos: 1. Si la solución actual tiene el nombre por omisión, ejecuta el caso de uso Guardar como.
Caso de uso: Guardar como
Descripción general: Guarda la solución actual de la información relacionada a las tres primeras etapas con el nombre y la ruta especificada.
Flujo básico:
Acción del actor Respuesta del sistema
1. Elige la opción Guardar como del Menú Archivo de la Ventana principal.
2. Muestra el cuadro de diálogo estándar para
guardar archivos (ver Figura 46).
3. Ubica la ruta deseada y digita el nombre de la solución con la extensión abea.
4. Presiona el botón Guardar del cuadro de diálogo estándar para guardar archivos.
5. Se cierra el cuadro de diálogo estándar para guardar archivos.
6. Guarda las 3 primeras etapas de la solución con el nombre y ruta especificada en el paso 3, en un archivo con un formato especial.
111
Precondiciones: 1. Que exista una solución a guardar.
Postcondiciones: 1. Se genera un archivo con extensión abea teniendo el nombre y la ruta dada por el usuario.
Flujos alternos: 1. Si presiona Cancelar en lugar de Guardar en el cuadro estándar Guardar, se cierra el cuadro de diálogo y
el archivo no es almacenado. 2. Si la ruta donde se pretende guardar un archivo no es válida, se le solicita al usuario que proporcione una
ruta válida.
Figura 46 Cuadro de diálogo estándar Guardar
Figura 47 Cuadro de diálogo estándar Abrir
112
Caso de uso: Abrir
Descripción general: Abre la solución de la ruta especificada cargando toda la información relacionada con la solución en los lugares correspondientes.
Flujo básico:
Acción del actor Respuesta del sistema
1. Presiona el botón Abrir en la barra de herramientas o elige opción Abrir del Menú Archivo en la Ventana principal.
2. Presenta el cuadro de diálogo estándar para abrir
un archivo (Ver Figura 47).
3. Selecciona la ruta y el archivo que desea abrir. 4. Presiona el botón “Abrir”. O da doble clic sobre
el archivo.
5. Cierra el cuadro de diálogo estándar. 6. Limpia todas las etapas de la herramienta. 7. Carga el contenido del archivo seleccionado en
las etapas correspondientes.
Precondiciones: 1. Que exista la solución que se desea abrir.
Postcondiciones: 1. Toda la información de la solución, es mostrada en las pestañas.
Flujos alternos: 1. Si existe una solución actual antes de dar clic en guardar, preguntar si ya guardo los cambios, si
selecciona la opción No, pregunta se desea guardar los cambios realizados, antes de mostrar el cuadro de diálogo “Abrir”, en caso de que desee guardar los cambios, se ejecuta el caso de uso Guardar.
Caso de uso: Seleccionar elemento
Descripción general: Le otorga el foco al elemento que fue cliqueado, distinguiéndolo con una flecha gris.
Flujo básico:
Acción del actor Respuesta del sistema 1. Da clic en el elemento que desea seleccionar.
2. Obtiene la posición x, y del clic.
113
3. Busca el elemento que corresponde con el área cliqueada.
4. Dibuja una flecha señalando el elemento cliqueado.
Precondiciones: 1. Que el clic sea en un elemento seleccionable del diagrama de flujo.
Postcondiciones: 1. Se muestra la flecha gris que identifica al elemento seleccionado. 2. Si el elemento es una estructura, habilita los botones de: Copiar, Cortar y Eliminar. Si el elemento es una
flecha de flujo color verde y existe un elemento almacenado en memoria temporal (es decir, que se haya copiado o cortado un elemento anteriormente), habilita el botón de Pegar.
Flujos alternos: 1. Si hace clic en un área inválida, no se dibuja la flecha blanca. Y si la flecha ya existe señalando a un
elemento, se borra.
Caso de uso: Copiar elemento
Descripción general: Copia el elemento seleccionado del diagrama de flujo.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento. 2. Da clic en el botón copiar ubicado en la barra de
herramientas estándar.
3. Copia el elemento que se ha seleccionado en
memoria temporal.
Precondiciones: 1. Debe haberse ejecutado el caso de uso seleccionar elemento.
Postcondiciones: 1. Guarda en memoria temporal el elemento seleccionado.
Flujos alternos: 1. Si selecciona un elemento del diagrama de flujo tipo flecha de color verde no permite el copiado del
elemento.
114
Caso de uso: Eliminar elemento
Descripción general: Elimina el elemento seleccionado del diagrama de flujo.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento. 2. Da clic en el botón borrar ubicado en la barra de
herramientas estándar.
3. Si el elemento seleccionado es de tipo secuencial elimina dicho elemento. Pero si el elemento es de tipo secuencial o cíclico, pregunta que si realmente desea eliminar el elemento con todo su contenido (Por ejemplo anidamientos), si responde que sí, elimina la estructura y sus elementos del diagrama de flujo.
4. Reacomoda el diagrama de flujo.
Precondiciones: 1. Debe haberse ejecutado el caso de uso Seleccionar elemento.
Postcondiciones: 1. El elemento eliminado desaparece del área de dibujo.
Flujos alternos: 1. Si selecciona un elemento del diagrama de flujo tipo flecha de color verde, no se permite la
eliminación del elemento. 2. Si el elemento es de tipo secuencial o cíclico y al hacerle la pregunta del paso 3, el usuario contesta
que no, no se ejecuta la eliminación del elemento.
Caso de uso: Cortar elemento
Descripción general: Corta el elemento seleccionado del diagrama de flujo.
Flujo básico:
Acción del actor Respuesta del sistema 1. Ejecuta el caso de uso Seleccionar elemento. 2. Da clic en el botón cortar ubicado en la barra de
herramientas estándar.
3. Ejecuta el caso de uso Copiar elemento con el
115
elemento seleccionado en el paso 1. 4. Ejecuta el caso de uso Eliminar elemento con el
elemento seleccionado en el paso 1.
Precondiciones: 1. Debe haberse ejecutado el caso de uso seleccionar elemento.
Postcondiciones: 1. El elemento cortado queda en memoria temporal y se elimina del diagrama
Flujos alternos: 1. Si selecciona un elemento del diagrama de flujo tipo flecha de color verde. No permite cortar el
elemento.
Caso de uso: Pegar elemento
Descripción general: Pega el elemento del diagrama de flujo que está en memoria temporal en la flecha seleccionada.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento. 2. Da clic en el botón pegar ubicado en la barra de
herramientas estándar.
3. Inserta el elemento que está en memoria temporal, por debajo del elemento flecha seleccionado en el diagrama de flujo.
4. Se redibuja el diagrama de flujo completo.
Precondiciones: 1. Seleccionar un elemento tipo flecha (de color verde) para insertar.
Postcondiciones: 1. El elemento se insertó debajo de la flecha seleccionada y el diagrama de flujo es redibujado.
Flujos alternos: 1. Si selecciona una estructura del diagrama de flujo, no permite pegar el elemento.
116
Caso de uso: Insertar elemento Leer
Descripción general: Inserta un elemento Leer, para poder aceptar datos de entrada.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento en un elemento tipo flecha insertable (de color verde).
2. Da clic en el botón Leer ubicado a la izquierda del área de dibujo.
3. Muestra el cuadro de diálogo Leer (ver Figura
48).
4. En el cuadro de texto, anota la(s) variable(s) que se desea leer.
5. Presiona el botón aceptar.
6. Verifica que la(s) variable(s) se halla(n) definido previamente.
7. Valida que el tipo de dato de la información de entrada sea correcta.
8. Cierra el cuadro de diálogo Leer. 9. Dibuja debajo de la flecha seleccionada, el
símbolo de lectura, con la(s) variable(s) dentro.
Precondiciones: 1. Seleccionar un elemento tipo flecha insertable. 2. La(s) variable(s) que se escribe(n) el cuadro de diálogo Leer, debe(n) estar definida(s) en la fase previa al
diseño.
Postcondiciones: 1. Se debe dibujar el elemento Leer en el área indicada y con las variables indicadas por el usuario.
Flujos alternos: 1. Si se oprime cancelar del cuadro de diálogo No se realiza la inserción del elemento Leer. 2. Si la(s) variable(s) no ha(n) sido definida(s) en la fase previa, emite una alerta al usuario para indicarle
este error, y además se distinguen de color rojo. 3. Si la(s) variable(s) no corresponden al tipo de dato solicitado, emite una alerta al usuario para indicarle
este error, y además se distinguen de color rojo.
117
Figura 48 Cuadro de diálogo para insertar elemento Leer
Caso de uso: Insertar elemento Calcular
Descripción general: Inserta un elemento Calcular, para realizar operaciones en el diagrama de flujo.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento en una flecha insertable.
2. Da clic en el botón Calcular ubicado a la izquierda del área de dibujo.
3. Muestra el cuadro de diálogo Calcular (ver
Figura 49).
4. En el cuadro de texto, anota la operación que desea añadir, a su correspondiente asignación.
5. Presiona el botón aceptar.
6. Verifica que antes de la operación exista una asignación.
7. Analiza que la operación sea coherente. 8. Verifica que la(s) variable(s) de la operación se
halla(n) definido previamente. 9. Cierra el cuadro de diálogo Calcular. 10. Dibuja debajo de la flecha seleccionada, el
símbolo de calcular con la operación dentro.
Precondiciones: 1. Se debe seleccionar una flecha válida para insertar el elemento Calcular.
118
2. La(s) variable(s) que se escribe(n) el cuadro de diálogo Leer, debe(n) estar definida(s) en la fase previa al diseño.
Postcondiciones: 1. Se debe dibujar el elemento Calcular debajo de la flecha seleccionada con la operación dada por el
usuario.
Flujos alternos: 1. Si no selecciona un elemento tipo flecha válido, no se realiza la inserción del elemento Calcular. 2. Si la variable(s) no ha(n) sido definida(s) en la fase previa, emite una alerta al usuario para indicarle
esta advertencia y pone las variables de color rojo.
Figura 49 Cuadro de diálogo para insertar elemento Calcular
Caso de uso: Insertar elemento Escribir
Descripción general: Inserta un elemento Escribir, que permite mostrar los valores de salida del diagrama de flujo.
Flujo básico:
Acción del actor Respuesta del sistema 1. Ejecuta el caso de uso Seleccionar elemento
sobre una flecha insertable. 2. Da clic en el botón Escribir ubicado a la
izquierda del área de dibujo.
3. Muestra el cuadro de diálogo Escribir (ver
Figura 50).
119
4. En el cuadro de texto, anota el mensaje de salida que desea mostrar.
5. Presiona el botón aceptar.
6. Verifica que la sintaxis del mensaje de salida sea correcto.
7. Verifica que las variables tengan rol de salida. 8. Cierra el cuadro de diálogo Escribir. 9. Dibuja en debajo de la flecha seleccionada, el
símbolo de Escribir, con el mensaje de salida dentro.
Precondiciones: 1. Se debe seleccionar un área válida para insertar el elemento Escribir. 2. La sintaxis del área de texto en el cuadro de diálogo escribir debe ser correcta
Postcondiciones: 1. Se debe dibujar el elemento Escribir en el área indicada y con el mensaje de salida dada por el usuario.
Flujos alternos: 1. No se realiza la inserción del elemento Escribir. 2. Si la variable(s) no ha(n) sido definida(s) en la fase previa, emite una alerta al usuario para indicarle esta
advertencia.
Figura 50 Cuadro de diálogo para insertar un elemento Escribir
Caso de uso: Insertar elemento Condicional
Descripción general: Inserta un elemento Condicional al diagrama de flujo.
Flujo básico:
120
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento en una flecha insertable.
2. Da clic en el botón Condición, ubicado a la izquierda del área de dibujo.
3. Muestra el cuadro de diálogo insertar elemento
Condición (ver Figura 51).
4. En el cuadro de texto anota la condición que se desea ejecutar.
5. Presiona el botón aceptar.
6. Verifica que la sintaxis del mensaje de la condición sea correcto.
7. Cierra el cuadro de diálogo Condición. 8. Dibuja debajo de la flecha seleccionada, el
símbolo de la estructura condicional, con la condición dada.
Precondiciones: 1. Se debe seleccionar una flecha insertable. 2. La sintaxis de la condición en el área de texto del cuadro de dialogo insertar elemento condición, debe ser
correcta.
Postcondiciones: 1. Se debe dibujar el elemento Condición en el área indicada y con el mensaje de salida dada por el usuario.
Flujos alternos: 1. Si el elemento seleccionado en el paso 1 no es una flecha insertable, no se añade el elemento
Condicional. 2. Si la variable(s) no ha(n) sido definida(s) en la fase previa, emite una alerta al usuario para indicarle esta
advertencia y las pone de color rojo.
121
Figura 51 Cuadro de diálogo para insertar un elemento Condicional
Caso de uso: Insertar ciclo Para.
Descripción general: Inserta una estructura cíclica de tipo Para.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento en una flecha insertable.
2. Da clic en el botón Para, ubicado a la izquierda del área de dibujo.
3. Muestra el cuadro de diálogo insertar elemento
ciclo Para (ver Figura 52).
4. Llena los datos indispensables para la creación del ciclo Para como lo son: la Inicialización, la condición y el incremento.
5. Presiona el botón aceptar.
6. Verifica que la sintaxis de la inicialización, la condición y el incremento, sean correctas.
7. Cierra el cuadro de diálogo insertar elemento ciclo Para.
8. Dibuja debajo de la flecha seleccionada, toda la estructura del ciclo Para que consiste en: un símbolo de Calcular para la inicialización, un símbolo de Condición para la condición de paro del ciclo y por último un símbolo de Calcular para el incremento.
122
Precondiciones: 1. Se debe seleccionar una flecha insertable para añadir el ciclo Para.
Postcondiciones: 1. Se debe dibujar los elementos del ciclo Para debajo de la flecha indicada. 2. No permite la inserción de ningún elemento entre los elementos de la inicialización y la condición de la
estructura del ciclo Para.
Flujos alternos: 1. Si el elemento seleccionado en el paso 1 no es una flecha insertable, no se añade los elementos de la
estructura Para. 2. Si la variable(s) no ha(n) sido definida(s) en la fase previa, emite una alerta al usuario para indicarle esta
advertencia y las pone de color rojo. 3. Si la sintaxis de la inicialización, condición o incremento no son correctos, emite un mensaje de
advertencia al usuario y colorea el texto de rojo.
Figura 52 Cuadro de diálogo para insertar un elemento Para
Caso de uso: Insertar ciclo Mientras.
Descripción general: Inserta una estructura cíclica de tipo Mientras.
Flujo básico:
Acción del actor Respuesta del sistema
1. Ejecuta el caso de uso Seleccionar elemento en una flecha insertable.
2. Da clic en el botón Mientras, ubicado a la izquierda del área de dibujo.
123
3. Muestra el cuadro de diálogo insertar
elemento ciclo Mientras (ver Figura 53).
4. En el área de texto anota la condición de paro del ciclo mientras.
5. Presiona el botón aceptar.
6. Verifica que la sintaxis de la condición sea correcta.
7. Cierra el cuadro de diálogo insertar elemento ciclo Mientras.
8. Dibuja debajo de la flecha seleccionada, la estructura del ciclo Mientras que consiste en un símbolo de Condición y una flecha de retorno.
Precondiciones: 1. Se debe seleccionar una flecha insertable para añadir el ciclo Mientras.
Postcondiciones: 1. Se debe dibujar los elementos del ciclo Mientras debajo de la flecha indicada por el usuario.
Flujos alternos: 1. Si el elemento seleccionado en el paso 1 no es una flecha insertable, no se añade los elementos de la
estructura Mientras. 2. Si la variable(s) de la condición no ha(n) sido definida(s) en la fase previa, emite una alerta al
usuario y las pone de color rojo. 3. Si la sintaxis de la condición no es correcta, emite un mensaje de advertencia al usuario y colorea el
texto de rojo.
Figura 53 Cuadro de diálogo para insertar un elemento Mientras
124
Caso de uso: Insertar ciclo Hasta.
Descripción general: Inserta una estructura cíclica de tipo Hasta.
Flujo básico:
Acción del actor Respuesta del sistema 1. Ejecuta el caso de uso Seleccionar
elemento en una flecha insertable. 2. Da clic en el botón Hasta, ubicado a la
izquierda del área de dibujo.
3. Muestra el cuadro de diálogo insertar
elemento ciclo Hasta (ver Figura 54). 4. Escribe la condición que se debe cumplir
para que el ciclo Hasta se repita. 5. Presiona el botón aceptar.
6. Verifica que la sintaxis de la condición sea válida.
7. Cierra el cuadro de diálogo insertar elemento ciclo Hasta.
8. Dibuja debajo de la flecha seleccionada la estructura del ciclo Hasta que consiste en una flecha donde inicia el ciclo, luego de un elemento condición.
Precondiciones: 1. Se debe seleccionar una flecha insertable para añadir el ciclo Hasta.
Postcondiciones: 1. Se debe dibujar los elementos del ciclo Hasta debajo de la flecha indicada por el usuario.
Flujos alternos: 1. Si el elemento seleccionado en el paso 1 no es una flecha insertable, no se añade los elementos de
la estructura Hasta. 2. Si la variable(s) de la condición no ha(n) sido definida(s) en la fase previa, emite una alerta al
usuario y pone el contenido de la condición de color rojo. 3. Si la sintaxis de la condición no es correcta, emite un mensaje de advertencia al usuario y colorea
el texto de rojo.
125
Figura 54 Cuadro de diálogo para insertar un elemento Hasta
Caso de uso: Traducir a
Descripción general: Traduce el diagrama de flujo a pseudocódigo o al lenguaje C.
Flujo básico:
Acción del actor Respuesta del sistema 1. Da clic en el botón Traducir algoritmo a.
2. Muestra el cuadro de diálogo que muestra las
opción de traducir a: Pseudocódigo y/o Lenguaje
C (ver Figura 55). 3. Elije la(s) opción(es). 4. Da clic en el botón Aceptar.
5. Traduce el diagrama de flujo a tipo de lenguaje
que el usuario eligió.
Precondiciones: 1. Debe haber sido compilado el diagrama de flujo y el resultado de dicha compilación debe ser
satisfactoria.
Postcondiciones: 1. Si la opción que eligió el usuario es el Lenguaje C, se genera un archivo con el mismo nombre de la
solución pero con la extensión c. 2. Si la opción que eligió el usuario es Pseudocódigo, se genera un archivo con el mismo nombre de la
solución pero con extensión txt.
Flujos alternos: 1. El usuario puede elegir las dos opciones por lo tanto se generan los dos tipos de archivos
mencionado en las Postcondiciones.
126
2. Si el usuario cierra el cuadro de diálogo que tiene las opciones a traducir, la traducción no se realiza.
Figura 55 Cuadro de diálogo Traducir a...
127
B. DIAGRAMAS DE CLASES
Figura 56 Diagrama de clases para ClaseAnalisis
Figura 57 Diagrama de clases para ClasePlaneacion
128
Figura 58 Diagrama de clases para DiagramaFlujo
129
Figura 59 Diagrama de clases para ClaseEjecutar
127
C. MANUAL DE USUARIO