UNIVERSIDAD DE MATANZAS “CAMILO CIENFUEGOS”
104
UNIVERSIDAD DE MATANZAS “CAMILO CIENFUEGOS” FACULTAD DE INFORMÁTICA TRABAJO DE DIPLOMA Herramienta Computacional “Suite de Geometría Descriptiva” Trabajo de Diploma en opción al Título de Ingeniería Informática Autor: Dayán Rodríguez Alonso Tutor: MSc. Antonio C. Fernández Orquín Matanzas, Cuba Junio 2009
Transcript of UNIVERSIDAD DE MATANZAS “CAMILO CIENFUEGOS”
UNIVERSIDAD DE MATANZAS
“CAMILO CIENFUEGOS”
FACULTAD DE INFORMÁTICA
TRABAJO DE DIPLOMA
Herramienta Computacional “Suite de Geometría Descriptiva”
Trabajo de Diploma en opción al Título de Ingeniería Informática
Autor: Dayán Rodríguez Alonso
Tutor: MSc. Antonio C. Fernández Orquín
Matanzas, Cuba
Junio 2009
A mi hermano, por cruzar la frontera de lo posible…
Agradecimientos
Quisiera agradecer ante todo a mis padres por su apoyo incondicional en cada etapa de
mi vida, al MSc. Antonio C. Fernández Orquín (Tony) quién siempre supo guiarme
sabiamente a lo largo de esta investigación. Me gustaría agradecer además a mi primo
Jorge Iván Cifuentes por sus consejos y su ayuda.
Declaración de autoría
Yo, Dayán Rodríguez Alonso, declaro que soy el único autor de este trabajo y autorizo a
la Universidad de Matanzas “Camilo Cienfuegos”, especialmente a la Facultad de
Informática, a que hagan el uso que estimen pertinente de él.
Y para que así conste, firmo la presente a los _________ días del mes de Junio del 2009.
______________ ______________
Firma del Autor Firma del Tutor
Opinión del tutor del trabajo de diploma
Título: Suite de Geometría Descriptiva.
Autor: Dayán Rodríguez Alonso.
El tutor del presente Trabajo de Diploma considera que durante su ejecución el estudiante
mostró las cualidades que a continuación se detallan.
Por todo lo anteriormente expresado considero que el estudiante está apto para ejercer
como Ingeniero Informático; y propongo que se le otorgue al Trabajo de Diploma la
calificación de: ________________
______________________________
MSc. Antonio C. Fernández Orquín
Resumen
La presente investigación tiene lugar en la Universidad de Matanzas “Camilo Cienfuegos”. Su objetivo es
la creación de una herramienta computacional para resolver ejercicios de Geometría Descriptiva. Esta
surge debido a que los libros y cuadernos no contienen la solución de los ejercicios y los profesores de la
asignatura, por cuestiones de tiempo y por la gran cantidad de ejercicios posibles, no pueden revisarlos
todos. Debido a esta situación el estudiante tiene problemas para aclarar sus dudas. El objeto de estudio
de este trabajo es la resolución y representación de ejercicios de Geometría Descriptiva mediante el uso
de la computadora. Los métodos utilizados en el desarrollo de este trabajo fueron los métodos empíricos e
históricos, siendo la observación de principal importancia. También se realizó la entrevista individual a los
profesores de la asignatura de Geometría Descriptiva. Para el desarrollo del proyecto de software se
utilizó la metodología RUP, la plataforma .Net con la utilización del lenguaje C# y DirectX Gestionado para
el trabajo con gráficos. Se emplearon cinco patrones de diseño para soportar una arquitectura flexible,
extensible y reutilizable. Este trabajo obtuvo como resultado una herramienta que funciona como
resolvedor de diez tipos de ejercicios y aporta un gran valor al estudio y a la enseñanza de esta
asignatura.
i
Tabla de Contenido
Introducción ....................................................................................................................................................... 1
Capítulo 1: Fundamentación teórica y tendencias tecnológicas...................................................................... 5
1.1 Introducción al capítulo ...................................................................................................................... 5
1.2 Antecedentes del trabajo ................................................................................................................... 5
1.3 Objeto de estudio. .............................................................................................................................. 5
1.3.1 Flujo actual de los procesos involucrados .................................................................................. 5
1.3.2 Análisis crítico de cómo se ejecutan actualmente estos procesos, las causas que originan la
situación problemática y las consecuencias. ........................................................................................... 6
1.4 Análisis del Estado del Arte. .............................................................................................................. 6
Procecad .................................................................................................................................................. 6
Descriptive Geometry .............................................................................................................................. 7
1.5 Análisis comparativo de otras soluciones existentes con la propuesta. ........................................... 7
1.6 Fundamento científico o marco teórico .............................................................................................. 9
1.6.1 Geometría Descriptiva ................................................................................................................... 10
1.6.2 Geometría Analítica ....................................................................................................................... 12
1.7 Descripción de las tendencias y tecnologías seleccionadas. .............................................................. 14
1.7.1 Rational Unified Process (RUP) .................................................................................................... 14
1.7.2 UML (Unified Modeling Languaje) ................................................................................................. 16
1.7.3 StarUML ......................................................................................................................................... 16
1.7.4 Visual Studio 2008 Professional .................................................................................................... 16
1.7.5 Lenguaje C# ................................................................................................................................... 18
1.7.6 Microsoft Direct3D Gestionado ...................................................................................................... 18
1.7.7 Patrones de diseños ...................................................................................................................... 19
1.8 Métodos de Investigación empleados .................................................................................................. 25
ii
1.9 Conclusiones del capítulo ..................................................................................................................... 25
Capítulo 2: Descripción y construcción de la solución propuesta.................................................................. 26
2.1 Introducción al capítulo ......................................................................................................................... 26
2.2 Descripción de la aplicación ................................................................................................................. 26
2.3 Requisitos del software ......................................................................................................................... 27
2.3.1 Requisitos funcionales ................................................................................................................... 27
2.3.2 Requisitos no funcionales .............................................................................................................. 28
2.4 Utilización del patrón MVC (Model-Viewer-Controller) ........................................................................ 28
2.4.1 Los modelos ................................................................................................................................... 29
2.4.2 Las vistas ....................................................................................................................................... 30
2.4.3 El controlador ................................................................................................................................. 31
2.5 Utilización del patrón Observer en el modelo activo del patrón MVC ................................................. 33
2.6 Utilización del patrón Simple Factory para desacoplar la creación de los modelos auxiliares ........... 34
2.6 Utilización del patrón Factory Method para desacoplar la creación de las clases ayudantes ............ 35
2.7 Utilización del patrón Singleton para evitar mostrar ventanas del mismo tipo .................................... 37
2.8 El trabajo con Direct3D ......................................................................................................................... 38
2.8.1 Representación de un sistema en abatimiento ............................................................................. 41
2.8.2 Representación de un sistema en isométrico ............................................................................... 43
2.9 Solución de los ejercicios de representación ....................................................................................... 45
2.10 Solución de los ejercicios de pertenencia, paralelismo e intersecciones .......................................... 47
2.11 Extensibilidad, Mantenimiento y reutilización ..................................................................................... 48
2.12 Elementos del estilo de códigos ......................................................................................................... 53
2.13 Conclusiones del capítulo ................................................................................................................... 54
Capítulo 3: Pruebas realizadas y resultados obtenidos ................................................................................. 55
3.1 Introducción al capítulo ......................................................................................................................... 55
iii
3.2 Estudio de Factibilidad .......................................................................................................................... 55
3.2.1 Estimación de costos del proyecto de software ............................................................................ 55
3.2.3 Beneficios Tangibles e Intangibles. ............................................................................................... 58
3.3 Técnicas de pruebas............................................................................................................................. 58
3.3.1 Pruebas de caja blanca ................................................................................................................. 60
3.3.2 Pruebas de caja negra ................................................................................................................... 68
3.4 Análisis de los resultados obtenidos .................................................................................................... 69
3.5 Criterios de los especialistas ................................................................................................................ 70
3.6 Documentación del sistema.................................................................................................................. 71
3.7 Conclusiones del capítulo ..................................................................................................................... 71
Conclusiones generales.................................................................................................................................. 72
Recomendaciones .......................................................................................................................................... 73
Referencias Bibliográficas .............................................................................................................................. 74
Bibliografía ...................................................................................................................................................... 76
Anexos ............................................................................................................................................................ 77
iv
Índice de figuras
Figura 1.1 Esquema del patrón MVC ........................................................................................................................... 21
Figura 1.2 Diagrama de clases del patrón Observer .................................................................................................... 22
Figura 1.3 Diagrama de clases del patrón Factory Method .......................................................................................... 23
Figura 1.4 Diagrama de clases del patrón Simple Factory ........................................................................................... 23
Figura 1.5 Diagrama de clases del patrón Singleton .................................................................................................... 24
Figura 2.1 Diagrama de clases del diseño que conforman el modelo en el patrón MVC ............................................. 29
Figura 2.2 El punto P representado en tres vistas diferentes. a) En abatimiento b) Sistema de coordenadas
cartesianas y c) Sistema en coordenadas polares. ...................................................................................................... 30
Figura 2.3 Diagrama de clases del diseño que conforman la vista en el patrón MVC .................................................. 31
Figura 2.4 Diagrama de clase del diseño que conforma el controlador en el patrón MVC ........................................... 32
Figura 2.5 Diagrama de clase del diseño que conforma el patrón Observer en el modelo activo de MVC .................. 33
Figura 2.6 Diagrama de clases del diseño que representan la utilización del patrón Simple Factory. ......................... 35
Figura 2.7 Diagrama de clases del diseño que representan la utilización del patrón Factory Method ......................... 36
Figura 2.8 Pasos en el trabajo con Direct3D ................................................................................................................ 38
Figura 2.9 Técnica de intercambio de buffers(13) ........................................................................................................ 40
Figura 2.10 Proyecciones soportadas en Direct3D ...................................................................................................... 40
Figura 2.11 Los dos sistemas de coordenadas utilizados por las API gráficas(13). ..................................................... 41
Figura 2.12 Transformación del sistema de mano izquierda para obtener la representación de un sistema en
abatimiento ................................................................................................................................................................... 42
Figura 2.13 Representación de un sistema en abatimiento utilizando Direct3D ........................................................... 43
Figura 2.14 Transformación del sistema de mano izquierda para obtener la representación de un sistema en
isométrico ..................................................................................................................................................................... 43
Figura 2.15 Representación de un sistema en isométrico utilizando Direct3D ............................................................. 44
Figura 2.16 Diagrama de bloques del algoritmo Representar ejecutado por la vista en abatimiento ........................... 46
Figura 2.17 Diagrama de clases del diseño que representan la relación entre las clases ControlDeExplicación y
D3DAbatimiento. ...................................................................................................................................................... 46
Figura 2.18 Diagrama de actividades para revolver un ejercicio de pertenencia, paralelismo o intersecciones .......... 47
Figura 2.19 Diagrama de clase de la librería de Geometría Analítica .......................................................................... 48
Figura 2.20 Las cuatro formas de extender la aplicación ............................................................................................. 48
Figura 2.21 Diagrama de clases que representa la extensión de la aplicación al agregar un nuevo modelo ............... 50
Figura 2.22 Diagrama de clases que representa la extensión de la aplicación al agregar una vista en abatimiento que
utiliza la API gráfica OpenGL. ...................................................................................................................................... 51
v
Figura 2.23 Diagrama de clases que representa la extensión de la aplicación al agregar una nueva vista que
presentan los modelos en coordenadas polares. ......................................................................................................... 52
Figura 3.1 Grafo de flujo para el código de la función llamada por el evento OnUpdate del controlador del ejercicio de
pertenencia de un punto a una recta. ........................................................................................................................... 64
Índice de tablas
Tabla 1.1 Análisis comparativo de las soluciones existentes con la propuesta construida. ........................................... 8
Tabla 2.1 Modelos y clases ayudantes ......................................................................................................................... 36
Tabla 2.2 Asociación entre las coordenadas utilizadas en el abatimiento y las del sistema de mano izquierda después
de ser rotado 1800 sobre el eje Z. ................................................................................................................................ 42
Tabla 2.3 Asociación entre las coordenadas utilizadas en la proyección isométrica y la del sistema de coordenadas
de mano izquierda transformado. ................................................................................................................................. 44
Tabla 3.1 Objetos identificados en la aplicación ........................................................................................................... 56
Tabla 3.2 Clases de equivalencias ............................................................................................................................... 69
1
Introducción
El ingeniero debe tener una concepción muy clara del espacio y de la representación de los objetos sobre
una superficie plana, así como del concepto de tridimensionalidad. Todo ello sirve de herramienta básica
en la lectura, ejecución, interpretación y dibujos de objetos; tanto en el proceso de concepción y diseño
como desde el punto de vista de su fabricación y producción. La geometría descriptiva resulta de
primordial importancia para las carreras de ingeniería, tanto en el proceso de formación como en el
ejercicio profesional, pues esta asignatura posee gran aplicación en la solución de problemas y en la
elaboración de diseños.
Los profesores de la asignatura de Geometría Descriptiva en las carreras de ingeniería en la Universidad
de Matanzas “Camilo Cienfuegos” han identificado que el principal problema que presentan los
estudiantes de dicha asignatura es la percepción espacial. A la mayoría de los alumnos les resulta
extremadamente difícil el entendimiento del objeto representado sobre una superficie plana así como el
traslado de un objeto tridimensional al plano y del plano al espacio.
Se puede plantear la situación problemática que existe a la hora de estudiar la Geometría Descriptiva de
la siguiente manera: Los libros de texto y cuadernos de ejercicios de la asignatura de Geometría
Descriptiva en las carreras de ingeniería no siempre muestran la representación tridimensional del objeto,
sólo la ortogonal en el plano. La mayoría de las veces no se incluye la proyección lateral, por lo que se
pierde la información del perfil del objeto. Los ejercicios incluidos en estos materiales no abarcan todas las
variantes. Un pequeño movimiento del objeto en el espacio puede tener distinta representación en el
plano y generar una gran cantidad de figuras, lo cual sería impráctico para un libro de texto. También los
ejercicios resueltos contienen una gran cantidad de trazos auxiliares que a veces entorpecen el
entendimiento del dibujo. Dichos trazos poseen el mismo color y sólo se distinguen por una mínima
diferencia de grosor. Los ejemplos en papel no se pueden modificar, además es imposible cambiar el
ángulo de observación para obtener una mayor comprensión. Los cuadernos no contienen la solución de
los ejercicios. Por otra parte, los profesores de la asignatura, por cuestiones de tiempo y por la gran
cantidad de ejercicios posibles, no pueden revisarlos todos. Debido a esta situación el estudiante tiene
problemas para aclarar sus dudas. En la figura I.1 se aprecia la complejidad de un ejercicio resuelto del
libro de texto de la asignatura.
2
Figura I.1 Ejercicio resuelto del libro de texto (1)
Con base a lo anteriormente expuesto se puede definir como Problema científico. ¿Podrá el uso de una
herramienta computacional resolver ejercicios de Geometría Descriptiva, mostrar la metodología utilizada
en la solución y representar los resultados en el plano y en el espacio? Por lo tanto el Objeto de estudio
es la resolución y representación de ejercicios de Geometría Descriptiva mediante el uso de la
computadora. Se define como Campo de acción de esta investigación, las representaciones en el plano y
en el espacio de los elementos geométricos: puntos, rectas, planos; y de las posiciones relativas e
intersecciones entre ellos.
De lo antes planteado se llega a la siguiente hipótesis: Si se utilizan patrones de diseño y la API1 gráfica
Direct3D2 se podrá desarrollar una herramienta computacional que resuelva los ejercicios de Geometría
Descriptiva, muestre la metodología utilizada en la solución y represente los resultados en el plano y en el
espacio.
1 API o Application Programming Interface es el conjunto de funciones que ofrece cierta biblioteca de código para ser
utilizado por otra aplicación como una capa de abstracción. 2 Ver epígrafe 1.7.6 Microsoft Direct3D Gestionado.
3
Las Variables de investigación son:
Variable independiente: La herramienta computacional creada.
Variables dependientes:
La solución de los ejercicios.
La metodología utilizada en la solución.
Las representaciones de los resultados en el plano y en el espacio.
Objetivo General:
Desarrollar una herramienta computacional que sea capaz de resolver ejercicios de Geometría
Descriptiva, que muestre los resultados en el plano y en el espacio, además de explicar la metodología
utilizada.
Objetivos Específicos:
Evaluar los posibles sistemas existentes relacionados con la Geometría Descriptiva.
Obtener las convenciones establecidas en la Geometría Descriptiva para el dibujo.
Realizar un amplio estudio de las tendencias y tecnologías actuales para determinar las que serán
utilizadas en el desarrollo del sistema.
Diseñar una interfaz de usuario interactiva y que sea lo más fácil posible de usar.
Crear los algoritmos que resuelvan cada tipo de ejercicio.
Novedad y aporte práctico
En la actualidad no existe un software en explotación utilizado como herramienta en la asignatura de
Geometría Descriptiva, impartida en la mayoría de las carreras de ingeniería estudiadas en el país. Los
estudiantes pueden conocer la solución correcta de un ejercicio, aprender la metodología de resolución y
aclarar las dudas sin la intervención del profesor. Además los profesores pueden utilizar esta herramienta
para complementar las presentaciones en PowerPoint dada la capacidad de mostrar y rotar los modelos
geométricos en el espacio. La aplicación Suite de Geometría Descriptiva desarrollada en este trabajo de
diploma aporta un recurso más en el estudio de dicha asignatura.
La investigación se estructura de la siguiente manera:
4
Capítulo 1: Fundamentación teórica y tendencias tecnológicas. Se describe el objeto de
estudio de forma más detallada, así como el marco teórico. Muestra un análisis comparativo de
propuestas existentes vinculadas al campo de acción. Además se abordan las tendencias y
tecnologías actuales utilizadas en el desarrollo del software.
Capítulo 2: Descripción y construcción de la propuesta. Se presentan los requisitos que se
tuvieron en cuenta para la confección de este software. Se explica el uso del patrón de diseño
MVC como soporte de todo el sistema y cómo el empleo de otros patrones ayuda a mejorar el
diseño para que este sea más extensible y reusable. También se describen las representaciones
de la proyección isométrica y el abatimiento de un sistema de tres planos de proyecciones
utilizando la API gráfica Direct3D incluida en Microsoft DirectX. Además se trata el tema de la
extensibilidad y reusabilidad, así como el estilo de códigos utilizado en la implementación de la
aplicación.
Capítulo 3: Elementos de prueba y resultados obtenidos. Se realiza un estudio de factibilidad
para el proyecto de software y se describen las técnicas de pruebas utilizadas en el proyecto. Se
aborda el análisis de los resultados obtenidos y la opinión de los especialistas.
5
Capítulo 1: Fundamentación teórica y tendencias tecnológicas
1.1 Introducción al capítulo
En este capítulo se describe el objeto de estudio de forma más detallada y los elementos teóricos que
ayudaron a entender la problemática y fueron la base teórica en la construcción del software realizado.
Además se muestra un análisis comparativo de propuestas existentes vinculadas al campo de acción. Por
último, se realiza un análisis de las tendencias tecnológicas utilizadas por el autor de este trabajo.
1.2 Antecedentes del trabajo
No se ha encontrado evidencia de la realización de herramientas informáticas que utilicen OpenGL3 o
DirectX y se encuentren en explotación en clases de Geometría Descriptiva en las carreras de ingeniería.
Sin embargo, los estudiantes de la Facultad de Informática de la Universidad de Matanzas han
desarrollando aplicaciones que resuelven problemas específicos en el campo de la Geometría Descriptiva
utilizando GDI+4. También se puede mencionar la existencia de una serie de ejercicios realizados en
PowerPoint.
1.3 Objeto de estudio.
El centro de atención de esta investigación radica en la resolución y representación de ejercicios de
Geometría Descriptiva mediante el uso de la computadora.
1.3.1 Flujo actual de los procesos involucrados
Los profesores de la asignatura de Geometría Descriptiva en las carreras de ingeniería de la Universidad
de Matanzas, imparten las conferencias utilizando presentaciones hechas en PowerPoint y se apoyan a
veces en la pizarra para representar algún dibujo sencillo. En las clases prácticas se orientan los
ejercicios, que los estudiantes resuelven de forma manual utilizando instrumentos de medición y aplicando
la teoría de la Geometría Descriptiva, pero sin realizar cálculos matemáticos. Una vez terminados los
ejercicios se entregan al profesor, quien revisa los resultados y señala los que son incorrectos.
3 OpenGL (Open Graphics Library) es una especificación estándar que define una API multilenguaje y
multiplataforma para desarrollar aplicaciones que produzcan gráficos 2D y 3D. 4 GDI+ es una librería que provee una interfaz que permite a los programadores escribir aplicaciones gráficas que
interactúan con dispositivos gráficos, impresoras y ficheros.
6
1.3.2 Análisis crítico de cómo se ejecutan actualmente estos procesos, las causas que originan la
situación problemática y las consecuencias.
Las conferencias utilizan presentaciones que contienen imágenes que no se pueden modificar, ni incluyen
todas las variantes posibles, además son apreciadas por estudiantes sentados en varios ángulos y
distancias del monitor de la computadora del aula. Cuando los profesores van a incluir una nueva
representación deben construirla utilizando programas de diseño como AutoCAD y salvar la imagen para
después modificar la conferencia. La representación en la pizarra de un ejercicio es trabajosa y consume
mucho tiempo del turno de clase. Los estudiantes resuelven los ejercicios en la libreta lo que también lleva
tiempo y al terminarlos no saben si están bien o mal, ya que los cuadernos no contienen la solución. Los
profesores de la asignatura por cuestiones de tiempo y por la gran cantidad de ejercicios posibles no
pueden revisarlos todos. Debido a esta situación el estudiante tiene problemas para aclarar sus dudas.
1.4 Análisis del Estado del Arte.
En el momento de la realización de esta tesis existían diversas aplicaciones relacionadas con la
Geometría Descriptiva, desarrolladas por estudiantes de informática que cursaron la asignatura Gráficos
por Computadoras. Pero estos programas sólo resuelven problemas específicos, no están diseñados para
ser extensibles y no utilizan una API gráfica con capacidades para gráficos tridimensionales. Sin embargo
se detectaron dos software comerciales relacionados con este campo que presentan características
atrayentes.
Procecad 5
Es un asistente de dibujo computarizado basado en la ejecución secuencial de procedimientos, el cual es
utilizado para complementar la enseñanza y el aprendizaje de la asignatura Geometría Descriptiva. Este
software ha sido diseñado como una herramienta alternativa de dibujo y no como un procesador de
elementos en tres dimensiones. Sin embargo, es posible crear y utilizar procedimientos que representen
elementos 3D en el plano de dibujo, mediante el uso de las proyecciones. (Ver Anexo 1)
Los modelos geométricos que Procecad representan son(2):
Puntos2D (Se grafican directamente)
Puntos3D (No se grafican hasta que sean proyectados por alguna función)
5 La versión trial de Procecad puede ser descarga de: www.geometriadescriptiva.com
7
Rectas
Semirrectas
Segmentos
Circunferencias
Cónicas (Elipses, Parábolas e Hipérbolas)
Arcos de circunferencias y arcos de curvas cónicas
Descriptive Geometry 6
Esta aplicación tiene como objetivo representar la solución de ejercicios de Geometría Descriptiva. El
usuario escribe una serie de procedimientos que son ejecutados por el programa para el dibujado de los
modelos geométricos. Estos algoritmos son escritos en un lenguaje de programación propio, derivado del
lenguaje C (Ver Anexo 2). Este software presenta las siguientes ventajas en comparación con el dibujado
de forma manual.
Precisión: Los cálculos son basados en la Geometría Analítica por lo cual tienen gran exactitud.
Velocidad: Los procedimientos se interpretan rápidamente y los dibujos son realizados en pocos
segundos.
Flexibilidad: Se puede modificar un punto y todos los modelos geométricos relacionados con dicho
punto cambian automáticamente.
Los modelos geométricos que Descriptive Geometry representan son:
Puntos2D
Rectas
Planos
Circunferencias
1.5 Análisis comparativo de otras soluciones existentes con la propuesta.
A continuación se muestra una tabla comparativa entre las dos aplicaciones comerciales mencionadas
anteriormente y la propuesta construida.
6 La versión trial de Descriptive Geometry puede ser descarga de: www.brothersoft.com.descriptive-geometry-
download-145555.html
8
Tabla 1.1 Análisis comparativo de las soluciones existentes con la propuesta construida.
Procecad Descriptive Geometry
1.32
Suite de Geometría
Descriptiva
Múltiples vistas
No. Sólo la
representación en el
plano y no incluye el
plano de perfil.
No. Sólo la
representación en el
plano y no incluye el
plano de perfil.
Si. Muestra la representación
del objeto en el plano y en el
espacio.
Facilidad de uso Difícil Difícil Fácil
Interactividad
Se construyen los
modelos geométricos
por comandos.
Se construyen los
modelos geométricos
mediante un lenguaje
de programación propio
derivado de C.
Se puede construir los
modelos geométricos
entrando las coordenadas de
los mismos o seleccionar los
ejemplos predefinidos y
modificarlos con el mouse.
Control de la
cámara. Sólo Zoom Sólo Zoom
Zoom y traslación en la vista
del Abatimiento.
Zoom, traslación y rotación en
la vista Isométrica.
Claridad en el
dibujo.
Buena. Se pueden
asignar el color y
grosor de los trazos.
Se puede dibujar por
capas y controlar la
visibilidad de las
mismas.
Aceptable. Se pueden
asignar el color y
grosor de los trazos.
Buena. Colores predefinidos
para una mejor identificación
entre los elementos comunes
de ambas vistas. Aunque se
puede asignar un color al
modelo principal. Grosor de
los trazos definidos por las
normas del dibujo. Control de
visibilidad de trazos, puntos
auxiliares y planos
coordenados. Transparencia
de planos.
9
Visualizar
ejercicios y
explicaciones
paso a paso
Si. Sólo visualización. Sólo en los ejercicios de
representación.
Explicaciones Si el autor del
ejercicio las define. No Si.
Resolvedor No No Si
Licencia Comercial Comercial Libre
Código fuente No No Si
API Gráfica GDI+ GDI Direct3D
Como se puede apreciar los sistemas Procecad y Descriptive Geometry 1.32 no cumplen del todo con los
requerimientos en la asignatura Geometría Descriptiva en las carreras de ingeniería de la Universidad de
Matanzas por lo que no se utilizan como una herramienta computacional para complementar dicha
asignatura.
1.6 Fundamento científico o marco teórico
Este epígrafe presenta los aspectos teóricos que constituyen las bases en la solución creada de una
forma que sea más asequible y permita un mayor entendimiento al ser utilizadas en el resto de los
capítulos. La herramienta computacional construida abarca los siguientes problemas:
Representación del punto.
Representación de la recta.
Representación del plano.
Pertenencia de un punto a una recta.
Pertenencia de una recta a un plano.
Pertenencia de un punto a un plano.
Paralelismo entre dos rectas.
Paralelismo entre una recta y un plano.
Intersección entre dos rectas.
Intersección entre una recta y un plano.
10
1.6.1 Geometría Descriptiva
La geometría descriptiva es un conjunto de técnicas de carácter geométrico que permite representar el
espacio tridimensional sobre una superficie bidimensional y por tanto, resolver en dos dimensiones los
problemas espaciales garantizando la reversibilidad del proceso a través de la adecuada lectura.
Como asignatura de estudio obligatorio en las escuelas de ingeniería y arquitectura, el estudio de la
Geometría Descriptiva persigue el desarrollo intelectual del estudiante en dos campos distintos pero
complementarios: la comprensión del espacio tridimensional que rodea al individuo y el desarrollo de una
estructura de pensamiento lógica, lo cual permite al profesional sentar las bases de otras disciplinas, como
la mecánica de cuerpos rígidos.
A continuación se expone la teoría de dicha geometría en la cual se basa el sistema construido.
Teoría de las proyecciones
El método de proyecciones es la base de cualquier representación y consiste en lo siguiente(3):
Sea un punto cualquiera en el espacio en calidad de centro de proyecciones o polo y un plano P llamado
plano de proyecciones que no pasa por dicho punto. Para proyectar un punto A sobre el plano de
proyecciones se hace pasar una recta a través del polo S y el punto A hasta que intercepte el plano P. El
punto de intercepción de esta línea con el plano es la proyección del punto A sobre el plano. La recta que
pasa por los puntos S y A recibe el nombre de recta o rayo proyectante. (Ver Anexo 3)
Proyección Ortogonal
En la práctica el método de proyección donde el rayo proyectante es perpendicular al plano de proyección
es el que tiene una mayor utilidad debido a las siguientes propiedades(3):
Una línea recta se proyecta en general en forma de línea recta siempre que no sea paralela a la
dirección de las rectas proyectantes.
Cada punto y cada línea en el espacio tienen en el plano de proyección una proyección única.
Para obtener las proyecciones de una línea recta es suficiente proyectar dos de sus puntos y trazar
una línea recta a través de las proyecciones obtenidas de estos dos puntos.
Si el punto pertenece a la recta, entonces la proyección del punto pertenece a la proyección de la
recta.
11
Las proyecciones de dos líneas rectas paralelas, son paralelas entre sí.
(Ver Anexo 4)
Proyección axonométrica
Como se explica en (3), este método consiste en que cualquier elemento geométrico puede ser referido a
un sistema de coordenadas y luego proyectado por rayos proyectantes perpendiculares a los planos
coordenados. Según la disposición de los ejes axonométricos pueden existir infinitas proyecciones
axonométricas, pero en el desarrollo de este trabajo de diploma se usará la proyección isométrica
ortogonal, la cual consiste en que el ángulo entre cada par de ejes es de 120 grados. (Ver Anexo 5)
Abatimiento en el sistema de dos planos
En la práctica los planos se representan en abatimiento. Para obtener el abatimiento en un sistema de dos
planos el plano F se mantiene inmóvil y se hace girar el plano H alrededor del eje OX hasta hacerlo
coincidir con el plano F. Así el semiplano anterior baja y el posterior sube. (VerAnexo 6)
Abatimiento en el sistema de tres planos
Para obtener el abatimiento en un sistema de dos planos el plano F se mantiene inmóvil y se hace girar el
plano H alrededor del eje OX hasta hacerlo coincidir con el plano F. Así el semiplano anterior baja y el
posterior sube. El plano L gira alrededor del eje OZ hasta coincidir también con el plano F haciendo que el
semiplano anterior de L gire hacia la derecha y el semiplano posterior gire hacia la izquierda(3).
(Ver Anexo 7)
Pertenencia de un punto a una recta
Para que un punto pertenezca a una recta las proyecciones del punto en abatimiento se deben encontrar
sobre las trazas de la recta.
Pertenencia de una recta en el plano
Una recta se encuentra en el plano si pasa a través de dos puntos que pertenezcan al plano o de un punto
que pertenezca al plano y es paralela a una recta del plano o a una recta paralela al plano(1).
Pertenencia de un punto a un plano
Un punto pertenece a un plano si pertenece a una recta contenida en dicho plano(1).
12
Paralelismo entre dos rectas
Dos rectas son paralelas si sus proyecciones Horizontales, Frontales y Laterales son paralelas
respectivamente. (Ver Anexo 8)
Paralelismo de una recta y un plano
Una recta es paralela a un plano si es paralela a una recta contenida en dicho plano(1). (Ver Anexo 9)
Intersección entre dos rectas
Dos rectas se cortan si el punto de intersección de las proyecciones homónimas se encuentra sobre una
perpendicular al eje de proyección correspondiente(1). (Ver Anexo 10)
Intersección entre una recta y un plano
Para determinar si hay intersección se recurre a un plano auxiliar que contiene a la recta. Si el plano
auxiliar corta el plano dado, forma una recta en la intersección de ambos. La intersección de estas dos
rectas es el punto de intersección buscado y por lo tanto existe intersección entre el plano y la recta(1).
(Ver Anexo 11)
1.6.2 Geometría Analítica
La Geometría Analítica es el estudio o tratamiento analítico de la geometría y fue presentada por primera
vez por René Descartes en su libro llamado Géometrie, que se publicó en el año 1637. En dicha obra se
estableció la relación explícita entre las curvas y las ecuaciones y podemos decir que además de
Descartes, todos los matemáticos de los siglos XVII y XVIII contribuyeron de una forma u otra al desarrollo
de esta nueva teoría. Dicha geometría se fundamenta en el uso de Sistemas de Coordenadas
Rectangulares o Cartesianas en honor a su fundador y es una parte de las matemáticas que se ocupa de
resolver algebraicamente los problemas geométricos.(4) Aunque este tipo de geometría no es utilizado por
los estudiantes de ingeniería en la asignatura de Geometría Descriptiva, sus ecuaciones sirven para la
realización de cálculos computacionales que soportan la solución desde un punto de vista descriptivo de
los ejercicios del software.
A continuación se presentan las fórmulas empleadas en la construcción de la solución planteada.
13
Forma general de la ecuación de una recta en el plano(5)
Ax + By + C = 0 1.1
A o B debe ser diferente de cero y C puede o no ser igual a cero.
Posiciones relativas de dos rectas dadas en su forma general(5)
Si la Forma General de la ecuación de dos rectas son Ax + By + C = 0 y A´x + B´y + C´ = 0, las relaciones
siguientes son condiciones necesarias y suficientes para:
a) Paralelismo: Si AB´ - A´B =0
b) Perpendicularidad: Si AA’ + BB’ = 0
c) Coincidencia: Si A = kA’, B = kB’, C = kC’ siendo (k ≠ 0)
d) Intersección en uno y solamente un punto AB’ – A’B ≠ 0
Ecuación vectorial del plano(6)
1.2
Donde:
es un vector normal al plano
P es un punto coplanar
d es la constante D del plano de la ecuación general de un plano
Punto medio de un segmento de recta(4)
1.3
Si los puntos se encuentran en el plano sus componentes z son iguales a cero.
Distancia entre dos puntos en el espacio(7)
1.4
Si los puntos se encuentran en el plano sus componentes z son iguales a cero.
14
Distancia de un punto a una recta(7)
1.5
Distancia de un punto a un plano(6)
1.6
Donde:
es un vector normal al plano
P1 es el punto al que se quiere calcular su distancia al plano
d es la constante D del plano de la ecuación general de un plano
1.7 Descripción de las tendencias y tecnologías seleccionadas.
1.7.1 Rational Unified Process (RUP)
El Proceso Unificado de Rational denota tres aspectos(8):
Es una metodología de desarrollo de software iterativa, centrada en arquitecturas y manejada por
casos de usos.
Es un proceso de ingeniería de software que determina quién es responsable de qué, cómo y
cuándo se hacen las cosas. También provee una configuración bien definida para el tiempo de vida
de un proyecto RUP.
Es un producto para procesos que nos provee un marco de trabajo adaptable para la ingeniería de
software.
RUP está estructurado a lo largo de dos dimensiones:
Tiempo: divide el tiempo de vida del proyecto en fases e iteraciones
Componentes de procesos: producción de un conjunto específico de artefactos definidos en
actividades.
Ambas dimensiones deben ser tomadas en cuentas para el éxito del proyecto.
Estructurar el proyecto a lo largo de la dimensión Tiempo implica la adopción de las siguientes fases.
15
Incepción: Especificación de la visión del proyecto
Elaboración: Planeamiento de las actividades necesarias y los recursos requeridos, especificación
de las características y diseño de la arquitectura.
Construcción: Construcción del producto como resultado de un series de iteraciones.
Transición: Administración del producto a la comunidad de los usuarios.
Estructurar el proyecto a lo largo de la dimensión Componentes de procesos incluye las siguientes
actividades.
Modelación del negocio: Identificación de las habilidades del sistema y las necesidades de los
usuarios.
Requerimientos: Narración de la visión del sistema y el conjunto de los requisitos funcionales y no
funcionales.
Análisis y diseño: Descripción de cómo será realizado el sistema en la fase de implementación.
Implementación: Producción del código que dará como resultado el sistema ejecutable.
Pruebas: Verificaciones del sistema.
Despliegue: Entrega del sistema y entrenamiento de los usuarios.
RUP se puede adaptar a las necesidades de cualquier proyecto. Si ninguno de los mapas metodológicos
definidos en RUP encajan con un proyecto, fácilmente se puede definir un mapa en específico, lo que
significa que este proceso puede ser tan ligero o pesado como se necesite.(9)
En (10), Jacobson, Booch y Rumbaugh expresan: “Un proceso de desarrollo de software es el conjunto de
actividades necesarias para transformar los requisitos de un usuario en un sistema. Sin embargo, el
Proceso Unificado es más que un simple proceso; es un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos.”
La solución aquí planteada puede ser abordada por cualquier metodología de software ágil, no obstante
se prevé que el software crezca en tamaño y complejidad a medida que los estudiantes de otros años lo
complementen a partir de esta propuesta para abarcar toda la materia de Geometría Descriptiva impartida
en las carreras de ingeniería. Por todo los antes planteado RUP es el camino a seguir.
16
1.7.2 UML (Unified Modeling Languaje)
UML es un lenguaje gráfico para especificar, construir, visualizar y documentar los artefactos de un
sistema de software. UML captura las decisiones y el entendimiento acerca del sistema a construir y está
diseñado para ser usado por cualquier metodología de desarrollo y en todas las etapas de la vida de un
proyecto de software. (11)
UML es un estándar relativamente abierto controlado por la OMG y es ampliamente utilizado en la
metodología RUP.
1.7.3 StarUML
StarUML es un producto Open Source para el desarrollo rápido y exacto de modelos de software basados
en el estándar UML. Soporta activamente la arquitectura MDA7, la metodología RUP y las versiones 1.4 y
2.0 del UML. Incluye Add-Ins8 para la generación de código C++, C# y Java, así como para la importación
de ficheros de Rational Rose, el intercambio de información con otras herramientas de modelado a través
del formato XMI y el trabajo con patrones de diseño. (Ver Anexo 12)
1.7.4 Visual Studio 2008 Professional
Microsoft Visual Studio es un entorno de desarrollo integrado (IDE, por sus siglas en inglés) para sistemas
operativos Windows. Soporta varios lenguajes de programación tales como Visual C++, Visual C#, Visual
J#, ASP.NET y Visual Basic .NET, aunque actualmente se han desarrollado las extensiones necesarias
para muchos otros. Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones
web, así como servicios web en cualquier entorno que soporte la plataforma .NET.
Visual Studio 2008 fue publicado el 17 de Noviembre de 2007 en inglés, mientras que la versión en
castellano no se publicó hasta el 2 de Febrero de 2008. El nuevo framework .Net 3.5 está diseñado para
aprovechar las ventajas que ofrece el nuevo sistema operativo Windows Vista a través de sus
subsistemas Windows Communication Foundation (WCF) y Windows Presentation Foundation (WPF). El
primero tiene como objetivo la construcción de aplicaciones orientadas a servicios, mientras que el último
apunta a la creación de interfaces de usuario más dinámicas que las conocidas hasta el momento. A las
7 MDA o Model Driven Architecture es una metodología de diseño de software, propuesto y patrocinado por el Object
Management Group. Esta proporciona un conjunto de guías para estructurar especificaciones expresadas como modelos. 8 Add-Ins es una aplicación que se relaciona con otra para aportarle una nueva función específica.
17
mejoras de desempeño, escalabilidad y seguridad con respecto a la versión anterior, se agregan entre
otras, las siguientes novedades.
• La mejora en las capacidades de Pruebas Unitarias permiten ejecutarlas más rápido,
independientemente de si lo hacen en el entorno IDE o desde la línea de comandos. Se incluye
además un nuevo soporte para diagnosticar y optimizar el sistema a través de las herramientas de
pruebas de Visual Studio. Con ellas se podrán ejecutar perfiles durante las pruebas para que
ejecuten cargas, prueben procedimientos contra un sistema y registren su comportamiento.
• Con Visual Studio Tools for Office (VSTO) integrado con Visual Studio 2008 es posible desarrollar
rápidamente aplicaciones de alta calidad basadas en la interfaz de usuario de Office que
personalicen la experiencia del usuario y mejoren su productividad en el uso de Word, Excel,
PowerPoint, Outlook, Visio, InfoPath y Project. Una completa compatibilidad para implementación
con ClickOnce garantiza el entorno ideal para una fácil instalación y mantenimiento de las
soluciones Office.
• Visual Studio 2008 permite incorporar características del nuevo Windows Presentation
Foundation. Debido a las mejoras en Microsoft Foundation Class Library (MFC) y Visual C++,
ahora es posible crear un estilo visual de las aplicaciones similar al de Windows Vista. Visual
Studio 2008 permite mejorar la interoperabilidad entre código nativo y código manejado por .NET.
Esta integración más profunda simplifica el trabajo de diseño y codificación.
• LINQ (Language Integrated Query) es un nuevo conjunto de herramientas diseñado para reducir
la complejidad del acceso a Base de Datos a través de extensiones para C++ y Visual Basic así
como para Microsoft .NET Framework. Permite filtrar, enumerar y crear proyecciones de muchos
tipos y colecciones de datos utilizando la misma sintaxis, prescindiendo así del uso de lenguajes
especializados como SQL o XPath.
• Visual Studio 2008 permite la creación de soluciones multiplataforma adaptadas para funcionar
con las diferentes versiones de .Net Framework: 2.0, 3.0 y 3.5.
18
• .NET 3.5 incluye biblioteca ASP.NET AJAX para desarrollar aplicaciones web más eficientes,
interactivas y altamente personalizadas que funcionen para todos los navegadores más populares
y utilicen las últimas tecnologías y herramientas Web, incluyendo Silverlight y Popfly.
1.7.5 Lenguaje C#
C# es un lenguaje de programación orientado a objetos desarrollado y estandarizado por Microsoft como
parte de su plataforma .NET aprobado como un estándar por la ECMA9 e ISO10. Su sintaxis básica deriva
de C/C++ y utiliza el modelo de objetos de la plataforma .NET, similar al de Java aunque incluye mejoras
derivadas de otros lenguajes.
C#, como parte de la plataforma .NET, está normalizado por ECMA desde diciembre de 2001. El 7 de
noviembre de 2005 se liberó la versión 2.0 del lenguaje que incluía mejoras tales como tipos genéricos,
métodos anónimos, iteradores, tipos parciales y tipos anulables. El 19 de noviembre de 2007 se lanzó la
versión 3.0 de C# destacando entre las mejoras los tipos implícitos, tipos anónimos y el LINQ (Language
Integrated Query).
Aunque C# forma parte de la plataforma .NET, esta es una interfaz de programación de aplicaciones
(API); mientras que C# es un lenguaje de programación independiente diseñado para generar programas
sobre dicha plataforma.
El autor de este trabajo de diploma decidió emplear C# dadas las facilidades que brinda y su
familiarización con este lenguaje.
1.7.6 Microsoft Direct3D Gestionado
En (12), Hoxley expresa: “El desarrollo de hardware demandante se ha acelerado exponencialmente en
los últimos años, de tal manera que la potencia para procesar gráficos tridimensionales está en manos de
todos, no sólo de grandes investigaciones o corporaciones importantes. Un procesador Pentium 4 y una
tarjeta de video con aceleración gráfica, provee más que suficiente poder para representar imágenes
tridimensionales a tiempo real.”
9 ECMA (European Computer Manufacteres Association) es una organización internacional para estandarizar el uso
de dispositivos electrónicos y de las Tecnologías de la Información y las Comunicaciones. 10
La Organización Internacional para la Normalización o ISO es el organismo encargado de promover el desarrollo de normas internacionales de fabricación, comercio y comunicaciones para todas las ramas industriales a excepción de la eléctrica y la electrónica.
19
Direct3D es parte de DirectX, una API propiedad de Microsoft disponible tanto en los sistemas Windows
de 32 y 64 bits como en sus consolas Xbox y Xbox 360 para la programación de gráficos 3D. El objetivo
de esta API es facilitar el manejo y trazado de entidades gráficas elementales, como líneas, polígonos y
texturas, presentes en cualquier aplicación que despliegue gráfico en 3D. Efectúa además de forma
transparente transformaciones geométricas sobre dichas entidades. Direct3D provee también una interfaz
para el trabajo con el hardware de aceleración gráfica. Se usa principalmente en aplicaciones donde el
rendimiento es fundamental, como los videojuegos, aprovechando la aceleración gráfica disponible en la
tarjeta de video. (13)
DirectX Gestionado fue lanzado con la versión DirectX 9 y posibilita a los programadores usar los
lenguajes .Net para desarrollar ricas aplicaciones gráficas. (13)
Existen otras API gráficas atractivas como OpenGL y GDI+.
OpenGL es una API gráfica muy utilizada ya que es un estándar abierto, portable y su uso es más
accesible que otras API, pero en el momento de comenzar este trabajo sólo existían librerías OpenGL
para .Net Framework 1.3 y constituían envolturas (Wrappers) hechas por terceros a librerías C de OpenGL
y la mayoría presentan errores o están incompletas.
GDI+ es la interfaz para dispositivos gráficos a partir del Sistema Operativo Windows XP que provee
trabajo con gráficos en dos dimensiones, imágenes y tipografías. GDI+ mejora a su antecesor GDI
añadiendo nuevas características y optimizando las existentes. GDI+ se puede programar en modo
gestionado desde .Net, pero su limitante a gráficos 3D lo descarta cómo candidato para la solución
planteada.
Por lo tanto Direct3D Gestionado es la solución apropiada por su completa integración en el modelo de
programación .Net, su soporte por la totalidad de los fabricantes de tarjetas de video y su rendimiento en
el trabajo con gráficos tridimensionales.
1.7.7 Patrones de diseños
Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas
comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un
patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un
20
patrón debe poseer ciertas características como su efectividad resolviendo problemas similares y su
aplicación a diferentes problemas de diseño en distintas circunstancias.(14)
De manera general los patrones tienen cuatro elementos esenciales(15):
1. El nombre del patrón permite describir en una palabra o dos el problema en el diseño, su solución
y sus consecuencias. Posibilita el diseño a un alto nivel de abstracción y hace más fácil pensar a la
hora de diseñar, comunicar las ideas y sus aspectos positivos y negativos.
2. El problema define cuándo aplicar el patrón. Explica la situación y su contexto. En algunos casos
el problema incluye una lista de condiciones que se deben satisfacer antes de aplicar el patrón.
3. La solución representa los elementos que construyen el diseño, sus relaciones, responsabilidades
y colaboraciones. Este elemento no describe un diseño o una implementación en específico, pues
un patrón cumple la función de una plantilla que puede ser utilizada en varias situaciones
facilitando una descripción abstracta de un problema de diseño. En lugar de ello el patrón
proporciona una descripción abstracta de un problema de diseño y demuestra cómo una
organización general de los elementos puede darle solución.
4. Las consecuencias constituyen los resultados que se derivan de aplicar el patrón. Aunque en la
mayoría de los casos no son expresadas a la hora de describir decisiones en el diseño, resultan
críticas para la evaluación de alternativas de diseño y para el entendimiento de los costos y
beneficios de la aplicación del patrón. Las consecuencias de un patrón incluyen su impacto en la
flexibilidad, extensibilidad y portabilidad del sistema, pues la reusabilidad es un factor en el diseño
orientado a objetos.
En el análisis de la solución de este proyecto se identificaron cinco patrones de diseño que se podían
implementar.
1.7.8.1 El patrón MVC (Model Viewer Controller)
MVC es un patrón de diseño fundamental en la separación de la interfaz de usuario de la lógica del
negocio. El patrón separa el modelado del dominio de la aplicación, la representación de la aplicación y
las acciones basadas en la interacción de los usuarios en tres objetos diferentes. (16)
Modelos: Estos objetos contienen todos los datos a ser representados y son responsables por
gestionar los datos de la aplicación.
21
Vista: Este objeto representa la información mostrada a los usuarios. Múltiples vistas pueden
mostrar la misma información en formas diferentes.
Controlador: Este objeto permite a los usuarios interactuar con los modelos de la aplicación. Las
vistas pueden invocar al controlador apropiado para que actúe sobre los modelos.
En la Figura 1.1 se presenta el esquema del patrón MVC. Las vistas representan los modelos y comunican
al controlador sobre cualquier cambio que se desea realizar a los modelos
Figura 1.1 Esquema del patrón MVC
Existen dos variantes de MVC: el modelo pasivo y el modelo activo.
En el modelo pasivo el controlador manipula de modo exclusivo al modelo. El controlador modifica al
modelo e informa a la vista que el modelo ha cambiado y que debe actualizarse. El modelo en este
escenario es completamente independiente de la vista y del controlador, lo que significa que el modelo no
puede notificar cambios en su estado a la vista a no ser que el cambio sea provocado por el controlador.
El modelo activo se usa cuando el modelo también necesita notificar cambios a la vista que no son
originados por el controlador. Sin embargo uno de los motivos de usar el patrón MVC es para hacer el
modelo independiente de la vista y si el modelo tiene que notificar sus cambios se reintroduce la
dependencia. Afortunadamente el patrón Observer se usa en la variante MVC de modelo activo para evitar
dicha dependencia. En la propuesta de la solución se utiliza el modelo activo.
1.7.8.2 El patrón Observer
22
El patrón Observer define una dependencia del tipo uno a muchos entre objetos, de manera que cuando el
objeto siendo observado cambia su estado, todos los objetos dependientes son notificados y actualizados
automáticamente.(17)
El objetivo de este patrón es desacoplar los objetos clientes del objeto observado, aumentando la
modularidad del lenguaje, así como evitar bucles de actualización. Este patrón también se conoce como el
patrón de publicación-inscripción o modelo-patrón. Estos nombres sugieren las ideas básicas del patrón,
que son bien sencillas: el objeto de datos o sujeto, contiene atributos mediante los cuales cualquier objeto
observador se puede suscribir a él pasándole una referencia a sí mismo. El sujeto mantiene así una lista
de las referencias a sus observadores. Los observadores a su vez están obligados a implementar
métodos determinados mediante los cuales el sujeto es capaz de notificar a sus observadores “suscritos”
los cambios que sufre para que todos ellos tengan la oportunidad de refrescar el contenido representado.
De manera que cuando se produce un cambio en el sujeto, este puede recorrer la lista de observadores
notificando a cada uno (14). En la Figura 1.2 se presenta el diagrama de clases del patrón Observer.
Figura 1.2 Diagrama de clases del patrón Observer
El patrón Observer se usa en las siguientes situaciones:
Cuando se quiere abstraer dos aspectos, uno dependiente del otro. Encapsular estos aspectos en
objetos separados permite variarlos y reusarlos de modo independiente.
Cuando cambios en un objeto requieren cambios en otros y no se sabe con certeza cuantos objetos
necesitan ser cambiados.
23
Cuando un objeto debe ser capaz de notificar otros objetos sin hacer asunción acerca del tipo de
objeto que son. En otras palabas no se quiere tener un alto acoplamiento entre estos objetos.
1.7.8.3 El patrón Factory Method
El patrón Factory Method define una interfaz para crear objetos, pero deja la decisión a sus subclases
sobre qué clases instanciar. La implementación clásica de Factory Method es una clase abstracta que
define un método para crear una familia de objetos (17). En la Figura 1.3 se presenta el diagrama de
clases del patrón Factory Method.
Figura 1.3 Diagrama de clases del patrón Factory Method
1.7.8.4 El patrón Simple Factory
El patrón Simple Factory es el más sencillo de las variantes de patrones Factory, el cual devuelve una
instancia entre varias posible. Por lo general se implementa construyendo una clase estática con un sólo
método que devuelve una instancia de una clase en dependencia del parámetro pasado al método.
El Simple Factory se usa cuando existe un conjunto de clases posibles para instanciar, pero la decisión de
cuál instanciar no se sabe hasta en tiempo de ejecución. En la Figura 1.4 se presenta el diagrama de
clases del patrón Simple Factory.
Figura 1.4 Diagrama de clases del patrón Simple Factory
24
Hay que tener en cuenta que Simple Factory no es uno de los 23 patrones de diseño definidos en GoF11 y
algunas bibliografías no lo consideran un patrón de diseño, sino más bien una buena práctica.
1.7.8.5 El patrón Singleton
El patrón Singleton asegura que una clase tenga sólo una instancia y provee un punto de acceso global a
ella. (17)
El patrón se implementa creando una clase con un método estático responsable de crear la única
instancia de la clase si no se ha creado. En caso de existir la instancia se devuelve una referencia. Para
asegurar que la clase no puede ser instanciada a través del operador new se regula el alcance del
constructor como protegido o privado.
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de ejecución. Si dos
hilos de ejecución intentan crear la instancia al mismo tiempo y esta no existe todavía, sólo uno de ellos
debe lograr crear el objeto. La solución clásica para este problema es utilizar exclusión mutua en el
método de creación de la clase que implementa el patrón.
Las situaciones más habituales de aplicación de este patrón son aquellas en las que dicha clase controla
el acceso a un recurso físico único, como puede ser el mouse o un archivo abierto en modo exclusivo, o
cuando cierto tipo de datos debe estar disponible para todos los demás objetos de la aplicación. En la
Figura 1.5 se presenta el diagrama de clases del patrón Singleton.
Figura 1.5 Diagrama de clases del patrón Singleton
11 GoF o Gang of Four es el nombre con el que se conoce comúnmente a los autores del libro Design Patterns:
Elements of reusable Object-Oriented Software. La banda de cuatro se compone de los siguientes autores: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.
25
1.8 Métodos de Investigación empleados
En el desarrollo de esta investigación se visitaron clases prácticas de la asignatura de Geometría
Descriptiva, donde se observaron cómo los estudiantes realizaban los ejercicios y se analizaron los
materiales de estudio. También se realizó la entrevista individual a los profesores de dicha asignatura,
quiénes explicaron la teoría asociada y aportaron criterios acerca de las funcionalidades que debía tener
la herramienta computacional propuesta. Además se efectuó un estudio de las aplicaciones existentes
relacionadas con este campo. Por lo tanto, podemos decir que los métodos utilizados en el desarrollo de
este trabajo fueron los métodos empíricos e históricos, siendo la observación de principal importancia.
1.9 Conclusiones del capítulo
Por lo anteriormente expuesto en los epígrafes de este capítulo el autor concluye que los sistemas
relacionados con el campo de la Geometría Descriptiva son escasos y no cumplen con los requerimientos
para ser implantados como complemento de dicha asignatura en las carreras de ingeniería de la
Universidad de Matanzas “Camilo Cienfuegos”. La API gráfica Direct3D, la plataforma .Net y el uso de los
patrones de diseño constituyen los pilares de la construcción de la solución planteada. La metodología
RUP fue adoptada por ser altamente flexible, previniendo el aumento del tamaño y la complejidad del
sistema, pues futuros trabajos de diploma podrían incluir otros elementos de la Geometría Descriptiva. En
la comparación realizada entre las aplicaciones existentes y la creada por este trabajo se demostró las
ventajas de esta última. Los aspectos teóricos reflejados contribuyen a la comprensión del problema y a
su solución mediante el uso de la computadora como una herramienta más de dicha asignatura.
26
Capítulo 2: Descripción y construcción de la solución propuesta.
2.1 Introducción al capítulo
La solución propuesta es la herramienta computacional Suite de Geometría Descriptiva. En este capítulo
se presentan los requisitos que se tuvieron en cuenta para la confección de este software. Se explica el
uso del patrón de diseño MVC como soporte de todo el sistema y cómo el uso de otros patrones ayuda a
mejorar el diseño para que este sea más extensible y reusable. También se describen las
representaciones de la proyección isométrica y el abatimiento de un sistema de tres planos de
proyecciones utilizando la API gráfica Direct3D incluida en Microsoft DirectX. Además se trata el tema de
la extensibilidad y reusabilidad, así como el estilo de códigos utilizado en la implementación de la
aplicación.
2.2 Descripción de la aplicación
El principal objetivo del software Suite de Geometría Descriptiva es actuar como resolvedor de diez tipos
de ejercicios de la asignatura. Esto permite a los estudiantes recrear los ejercicios de las clases prácticas
para obtener las soluciones con sus respectivas explicaciones y de este modo el alumno comprueba su
respuesta con la del sistema. También puede aprender la metodología de solución de los ejercicios.
La aplicación cuenta con diez ventanas que se corresponden con los tipos de ejercicios que abarca el
campo de acción de esta investigación:
Representación del punto.
Representación de la recta.
Representación del plano.
Pertenencia de un punto a una recta.
Pertenencia de una recta a un plano.
Pertenencia de un punto a un plano.
Paralelismo entre dos rectas.
Paralelismo entre una recta y un plano.
Intersección entre dos rectas.
Intersección entre una recta y un plano.
27
Los ejercicios de representaciones son capaces de demostrar la construcción del dibujo paso a paso con
su respectiva explicación. Todos los modelos geométricos representados se pueden modificar
seleccionando uno de sus puntos y arrastrándolo mientras se mantiene presionado el botón izquierdo del
mouse, lo que permite adaptar fácilmente un ejercicio o modificar los modelos hasta que se obtenga el
resultado esperado. En cada formulario se pueden crear varios ejercicios que pueden ser salvados para
su posterior recuperación. El software está confeccionado como una aplicación MDI12 para una mejor
gestión y organización de todas las ventanas abiertas.
2.3 Requisitos del software
El levantamiento de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que
debe ofrecer desde la perspectiva del usuario. A continuación se presentan los requisitos funcionales y no
funcionales que se tuvieron en cuenta a lo largo de todo el desarrollo del proyecto de software.
2.3.1 Requisitos funcionales
Múltiples Vistas: La aplicación debe ser capaz de mostrar la representación en la proyección
isométrica con la correspondiente representación en abatimiento de un ejercicio con el fin de lograr
una mayor percepción del ejercicio.
Cámaras independientes en las vistas: Se puede alejar, acercar, trasladar y rotar la cámara; así
como mostrar u ocultar puntos y trazos auxiliares en las vistas de forma independiente.
Representación y explicación paso a paso: Los ejercicios de representación deben explicar
paso a paso cómo se representa el modelo geométrico.
Listado de ejercicios: La aplicación debe permitir crear un listado de ejercicios. Cada ejercicio
podría ser mostrado o eliminado de la lista según la conveniencia del usuario.
Salvar y cargar el listado de ejercicios: El programa debe ser capaz de guardar un listado de
ejercicios para su posterior recuperación.
Tipos de modelos predefinidos: Se debe poder escoger de una lista las variantes clásicas de los
modelos geométricos.
12 Los programas con interfaz de múltiples documentos (MDI) son aquellos cuyas ventanas se encuentran dentro de
una ventana padre, normalmente con la excepción de las ventanas modales.
28
2.3.2 Requisitos no funcionales
Apariencia o interfaz de usuario (GUI): La interfaz es agradable, simple y de fácil uso. El uso
correcto de los colores permitirá un mayor entendimiento e identificación de elementos comunes
en las vistas. La apariencia está diseñada para no obstaculizar ninguna parte del dibujo en
cualquier momento, evitando el uso de ventanas y menús emergentes.
Facilidad de uso: El sistema está concebido para ser utilizado por cualquier usuario con un
mínimo de conocimientos del sistema operativo Windows. No se necesita el aprendizaje de
comandos o lenguajes de programación para la construcción de los ejercicios, todos se construyen
utilizando el mouse, y en caso de querer un mayor control se utiliza el teclado solamente para
introducir las coordenadas de los modelos geométricos.
Rendimiento: La velocidad de dibujado es lo suficientemente rápida para no mostrar un parpadeo
al modificar los modelos con el mouse o cambiar la posición de las cámaras.
Software:
- Microsoft Windows XP o superior.
- Microsoft Framework 3.5
- Microsoft DirectX 9c o superior
Hardware: Requisitos mínimos
- Pentium 4 o equivalente
- 256 MB de memoria
- Tarjeta de video con aceleración gráfica y con soporte para DirectX
2.4 Utilización del patrón MVC (Model-Viewer-Controller)
El patrón MVC constituye el diseño de clases que soporta el sistema y aporta los siguientes beneficios:
Desacopla las vistas de los modelos, lo que permite cambiar fácilmente las representaciones de
los modelos.
Las vistas encapsulan el trabajo con la API gráfica, en este caso Direct3D. Esto posibilita el
reemplazo de la vista por una que contenga una nueva versión de DirectX u otra API gráfica como
OpenGL.
Se puede reemplazar el controlador para cambiar la manera en que se modifican los modelos sin
afectar el funcionamiento de las demás clases.
29
2.4.1 Los modelos
Cada modelo debe implementar la interfaz IModelo, pues como se verá más adelante es esencial en la
implementación del patrón Factory Method. Las clases PuntoModel, RectaModel y PlanoModel
implementan IModelo y representan los conceptos geométricos punto, recta y plano respectivamente.
Los ejercicios están compuestos por un grupo de modelos y la aplicación mantiene una lista de ejercicios
que son administrados por el gestor de ejercicios. Las clases que implementan IModelo y la clase
Ejercicio están marcadas con la etiqueta [Serializable], lo cual indica que sus instancias pueden
ser serializables13. La serialización permite lograr la persistencia del listado de ejercicios en un fichero
para su posterior recuperación. En la Figura 2.1 se muestran las clases del diseño que conforman el
modelo en el patrón MVC.
Figura 2.1 Diagrama de clases del diseño que conforman el modelo en el patrón MVC
13 En ciencias de la computación, la serialización es el proceso de codificación del estado de un objeto en un medio
de almacenamiento para su posterior recuperación. Esta codificación puede ser binaria o en un formato humanamente más legible como XML o JSON. La serialización es un mecanismo ampliamente usado para transportar objetos a través de una red, para hacer persistente un objeto en un archivo o en una base de datos, o para distribuir objetos entre aplicaciones.
30
2.4.2 Las vistas
Las vistas son responsables de representar los modelos del ejercicio activo de diversas formas. En la
solución de esta propuesta se construyeron dos vistas que encapsulan el trabajo con Direct3D y
representan los modelos en abatimiento y en la proyección isométrica. Estas son representadas por las
clases D3DAbatimiento y D3DIsométrico respectivamente. Cada vista implementa la interfaz IVista
y es responsable de representar los modelos a su manera. En la Figura 2.2 se muestra cómo las vistas
que representan un sistema en abatimiento, un sistema en coordenadas cartesianas y un sistema en
coordenadas polares representarían un punto.
Figura 2.2 El punto P representado en tres vistas diferentes. a) En abatimiento b) Sistema de coordenadas cartesianas y c) Sistema en coordenadas polares.
Las clases D3DAbatimiento y D3DIsométrico heredan de UserControl. Esto permite que se
conviertan en controles de usuario que puedan ser seleccionados de la barra de herramientas de Visual
Studio. Al heredar de UserControl se crean controles compuestos que no son más que una colección
de controles de Windows Form encapsulados en un contenedor común. Los controles que componen las
vistas son dos paneles. El primero contiene los botones que controlan algunos aspectos de la cámara y en
el segundo se sobrescribe el evento OnPaint para dibujar la representación de la vista utilizando
Direct3D.
31
La clase VistaState tiene como objetivo guardar el estado de una vista. Ella almacena el
desplazamiento de la cámara y el factor de zoom. Además indica si se muestran las notaciones, los trazos
y puntos auxiliares del dibujo, así como si se encuentra habilitada o deshabilitada la transparencia de los
planos. En la Figura 2.3 se muestran las clases del diseño que conforman la vista en el patrón MVC.
Figura 2.3 Diagrama de clases del diseño que conforman la vista en el patrón MVC
2.4.3 El controlador
La función del controlador es actuar sobre los modelos a petición de la vista. Cuando el usuario realiza un
clic en la vista, esta solicita al controlador que realice una búsqueda del modelo más cercano a las
32
coordenadas del clic y al mover el mouse, mientras se mantiene presionada su tecla izquierda, el
controlador cambia las coordenadas del modelo previamente seleccionado e informa al gestor de
ejercicios del cambio realizado, quien a su vez notifica a todas las vistas registradas mediante el patrón
Observer.
La clase Controlador implementa la interfaz IControlador por lo que se tienen que definir los métodos
Buscar y Mover. El método Buscar encuentra el modelo que se quiere seleccionar en el ejercicio activo del
gestor de ejercicios y almacena una referencia para futuras modificaciones. El método mover tiene dos
parámetros, el primero es la nueva posición del mouse que sirve para hallar la dirección en que se moverá
el modelo seleccionado. El segundo es un valor booleano, el cual es verdadero si se mantiene presionada
la tecla Shift mientras se modifica el ejercicio arrastrando el mouse, esto posibilita que el incremento sea
de 0.1 punto, logrando una mayor precisión en la modificación de la figura.
La única clase controlador implementada en este proyecto sólo permite mover un punto a la vez. Si se
deseara, se pudiera crear un nuevo controlador y definir el método Mover para que se modifiquen todos
los puntos de una figura a la vez, haciendo que esta se traslade de lugar. En la Figura 2.4 se muestran las
clases del diseño que conforman la vista en el patrón MVC.
Figura 2.4 Diagrama de clase del diseño que conforma el controlador en el patrón MVC
33
2.5 Utilización del patrón Observer en el modelo activo del patrón MVC
En el modelo pasivo del patrón MVC el controlador es el encargado de realizar cambios en los modelos y
notificarlos a las vistas. Debido a las características de este software también ocurren cambios en los
modelos sin la intervención del controlador, como son la adición, eliminación o selección de un ejercicio en
el gestor de ejercicios. Estos cambios deben ser informados a las vistas para su debida actualización. Por
lo antes explicado los modelos deben ser los responsables de notificar los cambios. Sin embargo en (18)
se plantea que una de las motivaciones de utilizar el patrón MVC es hacer los modelos totalmente
independientes de las vistas y si los modelos tienen que notificar a las vistas de los cambios se
reintroduce la dependencia. Para evitar esto, se utiliza el patrón Observer, lo que constituye el modelo
activo del patrón MVC.
Las vistas D3DAbatimiento y D3DIsométrico implementan la interfaz IObservador, esto les permite
registrase para recibir notificaciones y poder actualizarse. El gestor de modelo implementa la interfaz
ISujeto que permite mantener una lista de todos los observadores subscritos que serán notificados de
los cambios. En la Figura 2.5 se muestra la utilización del patrón Observer en el modelo activo de MVC.
Figura 2.5 Diagrama de clase del diseño que conforma el patrón Observer en el modelo activo de MVC
34
2.6 Utilización del patrón Simple Factory para desacoplar la creación de los modelos auxiliares
Como se ha especificado anteriormente las vistas son responsables de representar los modelos de
distintas maneras. Por ejemplo en la representación de un punto en abatimiento que muestra el plano
lateral se dibujan siete puntos y nueve líneas. (Ver Figura 2.2a), pero la representación de una recta en la
misma vista y mostrando el plano lateral contiene catorce puntos y veintiuna líneas. Para ello se necesita
programar la vista para representar correctamente cada modelo de la siguiente manera.
private List<IModelo> lista = new List<IModelo>();
if (modelo is PuntoModel)
{
// Llenar la lista con los modelos auxiliares que representan un punto en
abatimiento
}
else
{
if (modelo is RectaModel)
// Llenar la lista con los modelos auxiliares que representan una
recta en abatimiento
else
{
…
}
}
¿Qué pasaría si se quisiera representar un nuevo modelo o reutilizar la misma lógica en otra vista en
abatimiento que utiliza OpenGL? En el primer caso hay que modificar el código fuente para acomodar
nuevos modelos. En el segundo, se requiere repetir el código anterior en cada una de las vistas en
abatimiento. En cualquiera de los casos este tipo de código hace el mantenimiento y la actualización más
difíciles y propicios a errores.
Para solucionar esto se utiliza una implementación particular del patrón Simple Factory, donde el código
anterior se encapsula en la clase AbatimientoSimpleFactory. Esta se encarga de devolver la lista
con los modelos auxiliares que constituyen la representación del modelo pasado como parámetro en el
35
método fabricar. Esta clase puede ser reutilizada entre vistas que comparten la misma representación.
Dichas vistas pueden tener conocimientos de cómo representar nuevos modelos utilizando el patrón
decorador o una nueva clase Simple Factory que reconozca cómo responder a los nuevos modelos
pasados como parámetros. En la Figura 2.6 se muestran las clases del diseño que representan la
utilización del patrón Simple Factory.
Figura 2.6 Diagrama de clases del diseño que representan la utilización del patrón Simple Factory.
2.6 Utilización del patrón Factory Method para desacoplar la creación de las clases ayudantes
Una vez obtenido el listado de los modelos auxiliares, las vistas necesitan saber dibujarlos mediante la
utilización de las instrucciones de Direct3D correspondientes. Esto devuelve a la situación anterior, ya que
si se emplea el código que dibuje cada tipo de modelo se introduce alto acoplamiento y baja cohesión.
Esto dificulta la manera de hacer “conscientes” a las vistas de cómo dibujar los nuevos modelos que se
pudieran crear en el futuro. El problema se pudiera resolver utilizando nuevamente el patrón Simple
Factory, pero como se explica a continuación se decidió utilizar otro patrón. Cada vista sólo es
responsable de la inicialización de Direct3D, así como de la representación de sus ejes y planos de
coordenadas utilizando la configuración de la cámara correcta. Luego, para dibujar cada modelo auxiliar
se utilizan clases ayudantes. Por cada tipo de modelo existe al menos una clase ayudante que contiene el
código Direct3D correspondiente para dibujarlo. Hay que tener en cuenta que se pueden tener varias
clases ayudantes que representen el mismo modelo, pero utilizando diferentes técnicas y efectos. En la
36
tabla 2.1 se presentan los modelos y las clases ayudantes que saben cómo representarlos mediante la
utilización de las instrucciones de Direct3D correspondientes.
Tabla 2.1 Modelos y clases ayudantes
Modelos Clases ayudantes
PuntoModel D3DHLPunto
RectaModel D3DHLRecta
PlanoModel D3DHLPlano
Debido a lo anteriormente explicado se decidió utilizar el patrón Factory Method. Este patrón define una
interfaz para la creación de los ayudantes, pero deja la decisión a sus subclases sobre qué clase ayudante
instanciar. En este trabajo sólo se creó la subclase D3DLowFactory que utiliza las características menos
demandantes en términos de recursos de hardware, abriendo el margen de tarjetas de video soportadas.
En equipos que contengan buenas capacidades gráficas, estas estarían subutilizadas si se empleara esta
subclase. La solución sería la creación de una subclase D3DHighFactory que utilice todos los recursos
disponibles obteniendo como resultado gráficos más realistas y que la aplicación según las capacidades
detectadas utilice la subclase adecuada. Hay que tener en cuenta que dicha solución está más allá del
ámbito del proyecto realizado, pero el buen diseño que trae consigo la utilización del patrón Factory
Method permite soportar fácilmente estos cambios en el futuro. En la Figura 2.7 se muestran las clases
que representan la utilización de este patrón.
Figura 2.7 Diagrama de clases del diseño que representan la utilización del patrón Factory Method
37
2.7 Utilización del patrón Singleton para evitar mostrar ventanas del mismo tipo
Los formularios de ejercicios son creados y mostrados a través del menú de la ventana principal de la
aplicación. ¿Qué pasaría si se selecciona un tipo de ejercicio cuya ventana ya se esté mostrando? Se
ejecutarían dos instancias de formularios del mismo tipo. Este comportamiento quizás sea el adecuado
para un procesador de textos dónde se quisieran crear varias ventanas de documentos al mismo tiempo,
pero no tiene sentido, por ejemplo, tener dos ventanas abiertas de intersección de una recta con un plano
si con una sola se pueden resolver varios ejercicios. La solución a este problema radica en la utilización
del patrón Singleton. Para su implementación el constructor de la clase se hace privado. Entonces sólo la
misma clase puede llamar a su constructor, pero esto no tendría sentido, pues se necesitaría tener una
instancia primero. La respuesta es la creación de un método estático que compruebe si ya existe una
instancia de la clase y devuelva su referencia. En caso de no existir, primero se crea la instancia antes de
retornarla. A continuación se presenta un fragmento del código en C# para obtener una mayor perspectiva
de la implementación del patrón.
public partial class PuntosForm : Form
{
private static PuntosForm instancia = null;
private PuntosForm()
{
// Código del constructor
}
public static PuntosForm ObtenerInstancia()
{
if (instancia == null)
instancia = new PuntosForm ();
return instancia;
}
}
Luego para crear una instancia de la clase sólo hay que utilizar el código siguiente:
PuntosForm form = PuntosForm.ObtenerInstancia();
38
2.8 El trabajo con Direct3D
Para el trabajo con Direct3D se utilizaron cinco pasos como se muestra en la Figura 2.8. Los pasos 1 y 2
sólo se ejecutan una vez al abrirse cada ventana de ejercicios, mientras que los pasos 3, 4 y 5 se ejecutan
cada vez que sea necesario refrescar cada vista.
Figura 2.8 Pasos en el trabajo con Direct3D
El primer paso en la inicialización Direct3D es la verificación de las capacidades del hardware gráfico.
Para ello se utiliza el método estático GetDeviceCaps() de la clase Manager que retorna una
instancia de la clase Caps. Esta instancia contiene un listado de todas las funcionalidades soportadas
por la tarjeta de video. Con dicho listado se puede analizar si la tarjeta de video soporta los cálculos
involucrados en el procesamiento de vértices en su GPU14, de lo contrario este trabajo es delegado a la
CPU15 de la computadora. Esto permite que la aplicación pueda ser ejecutada por una mayor cantidad de
máquinas con distinta potencia gráfica.
14 La unidad de procesamiento gráfico o GPU (Graphics Processing Unit) es un procesador dedicado exclusivamente
al trabajo con gráficos, que se utiliza para aligerar la carga de trabajo del CPU en aplicaciones como los videojuegos y/o aplicaciones 3D interactivas. De esta forma, mientras gran parte de lo relacionado con los gráficos se procesa en la GPU, la CPU puede dedicarse a otro tipo de cálculos.
15 La unidad central de procesamiento, o CPU (Central Processing Unit), o simplemente, el procesador, es el
componente de una computadora que interpreta las instrucciones y procesa los datos contenidos en los programas de la computadora.
Verificación de las capacidades del hardware gráfico
Creación del dispositivo gráfico
Preparación de la escena
Dibujado de la escena
Finalización y presentación de la escena
Paso 1
Paso 2
Paso 3
Paso 4
Paso 5
39
El segundo paso consiste en la creación del dispositivo gráfico, que crea una capa de abstracción con el
hardware gráfico (HAL16). Para ello, se crea una instancia de la clase Device para cada vista. Entre los
parámetros pasados al constructor de dicha clase se encuentran: el control dónde se dibujará usando
Direct3D y una bandera que indica si los cálculos serán realizados por la CPU o la tarjeta de video,
teniendo en cuenta las características identificadas en el primer paso.
El tercer paso consiste en la preparación de la escena. Para ello se le asigna al dispositivo un espacio en
la memoria de la tarjeta de video y se le indica a través del método BeginScene() que se prepare para
recibir datos y escribirlos en dicha memoria.
El cuarto paso es el dibujado de la escena. Comienza cuando se definen las matrices de transformación a
utilizar (tipo de proyección, posición de la cámara, posición de cada objeto) y las clases ayudantes dibujan
los modelos que componen la escena. Además se configura la intensidad, tipo y dirección de las fuentes
de luz.
El último paso consiste en la finalización y presentación de la escena. Este se ejecuta cuando se han
terminado de dibujar los objetos y se llama al método EndScene() para indicar que se debe prohibir el
acceso al área de memoria que contiene el dibujo. Posteriormente se llama al método Present() para la
representación en pantalla del dibujo a través de la técnica de cadena de intercambio de buffers17. Esta
técnica consiste en un buffer principal (front buffers) que almacena el contenido mostrado en pantalla y
uno o más buffers traseros (back buffers) en los cuales ocurre el dibujado de los gráficos. Cuando se
termina el trabajo con un buffer trasero, este pasa a ser el buffer principal permitiendo la representación
inmediata de los gráficos en la pantalla En la Figura 2.9 se representa dicha técnica.
16 La capa de abstracción de hardware (Hardware Abstraction Layer o HAL), es un elemento del sistema operativo
que funciona como una interfaz entre el software y el hardware del sistema, para proveer una plataforma de hardware consistente, sobre la cual corren las aplicaciones. Cuando se emplea una HAL, las aplicaciones no acceden directamente al hardware sino que lo hacen a través de la capa abstracta provista por la HAL, lo que permite que las aplicaciones sean independientes del hardware.
17 Un buffer de datos es una ubicación en la memoria de una computadora o en un instrumento digital, reservada
para el almacenamiento temporal de información digital, mientras espera para ser procesada.
40
Figura 2.9 Técnica de intercambio de buffers(13)
Direct3D soporta dos tipos de proyecciones que son utilizadas en el cuarto paso(19):
Proyección Perspectiva: Ajusta la representación del objeto según la distancia Z, lo que hace que
los objetos aparezcan más pequeños a medida que se alejan de la pantalla. Los objetos se
deforman como en el mundo real, por ejemplo, los bordes de la carretera parecen juntarse en el
horizonte. (Ver Figura 2.10 a)
Proyección Ortogonal: Los objetos aparecen del tamaño definido originalmente, no se hacen más
grande cuando se acercan a la pantalla o más pequeños cuando se alejan. (Ver Figura 2.10 b)
Figura 2.10 Proyecciones soportadas en Direct3D
Se utilizó la Proyección Ortogonal el trabajo con Direct3D, al ser esta la empleada en los materiales de la
asignatura Geometría Descriptiva. Para ello se llamó al método estático OrthoLH de la clase Matrix,
que crear la matriz adecuada para la representación ortogonal.
41
2.8.1 Representación de un sistema en abatimiento
Direct3D utiliza el sistema de coordenadas de mano izquierda, a diferencia de OpenGL que se apoya un
sistema de mano derecha. En ambos sistemas las coordenadas positivas de las X se mueven hacia la
derecha y las Y positivas hacia arriba. La diferencia se encuentra en el eje Z. En el sistema de mano
izquierda utilizado, las coordenadas positivas de las Z se mueven desde el usuario hacia dentro de la
pantalla de la computadora. En la Figura 2.11 se muestra estos dos sistemas.
De igual manera no existe ninguna transformación directa aplicada a un sistema de mano izquierda para
crear un sistema en abatimiento. Debido a esto el paso más lógico a seguir es hacer coincidir la mayor
cantidad de ejes posibles entre estos dos sistemas, por lo que el sistema de coordenadas se hace girar
1800 sobre el eje Z en contra de las manecillas del reloj. En la Figura 2.12 se aprecia como queda el
sistema de mano izquierda después de realizada la rotación. En este momento las coordenadas positivas
de las X coinciden y las coordenadas positivas de las Y se convierten en YH+. En la tabla 2.2 se muestra
la asociación entre las coordenadas utilizadas en el abatimiento y las del sistema de coordenadas de
mano izquierda después de ser rotado 1800 sobre el eje Z.
Figura 2.11 Los dos sistemas de coordenadas utilizados por las API gráficas(13).
42
Figura 2.12 Transformación del sistema de mano izquierda para obtener la representación de un sistema en abatimiento
Tabla 2.2 Asociación entre las coordenadas utilizadas en el abatimiento y las del sistema de mano izquierda después de ser rotado 180
0 sobre el eje Z.
Abatimiento
(Ver figura 2.2a)
Sistema de mano
izquierda rotado
x+ x+
x- x-
yh+ y+
yh- y-
yl+ x-
yl- x+
z+ y-
z- y+
Para representar los ejes de coordenadas del sistema en abatimiento se trazan las líneas siguientes:
Una línea de color rojo desde el punto (1000, 0, 0) hasta el origen para representar el eje X+.
Una línea de color verde desde el punto (0, 1000, 0) hasta el origen para representar el eje YH+.
Una línea de color verde desde el origen hasta el punto (-1000, 0, 0) para representar el eje YL+.
Una línea de color azul desde el origen hasta punto (1000, 0, 0) hasta el origen para representar el
eje Z.
43
Además se dibujan tres rectángulos que representan los planos XY, YZ y XZ para lograr una mayor
identificación, ya que estos planos en la vista en isométrico tendrán los mismos colores. En la Figura
2.13 se presenta la representación en abatimiento utilizando Direct3D.
Figura 2.13 Representación de un sistema en abatimiento utilizando Direct3D
2.8.2 Representación de un sistema en isométrico
Para lograr la representación de un sistema en isométrico se rota 900 sobre el eje X de tal forma que las
coordenadas positivas de la Z queden hacia abajo. En este momento las coordenadas Y positivas entran
hacia la pantalla, las Z positivas se mueven hacia abajo y las X positivas se mueven hacia la derecha.
Luego para obtener el ángulo de vista correcto se posiciona la cámara en un punto que equidista de los
tres ejes de coordenadas y se encuentra en el primer octante. Además la cámara debe estar enfocada
hacia el origen (Ver Figura 2.14). En la tabla 2.3 se muestra la asociación entre coordenadas utilizadas en
la proyección isométrica y la del sistema de coordenadas de mano izquierda rotado.
Figura 2.14 Transformación del sistema de mano izquierda para obtener la representación de un sistema en isométrico
44
Tabla 2.3 Asociación entre las coordenadas utilizadas en la proyección isométrica y la del sistema de coordenadas de mano izquierda transformado.
Isométrico Sistema de mano izquierda rotado
X+ X+
X- X-
Y+ Y+
Y- Y-
Z+ Z-
Z- Z+
Para representar los ejes de coordenadas del sistema en isométrico se trazan las líneas siguientes (ver
Figura 2.15 a):
Una línea de color rojo desde el punto (1000, 0, 0) hasta el punto (0, 1000, 0) para representar el
eje X.
Una línea de color verde desde el punto (0, 1000, 0) hasta el punto (0, -1000, 0) para representar
el eje Y.
Una línea de color azul desde el punto (0, 0, 1000) hasta el punto (0, 0, -1000) para representar el
eje Y.
Para representar los planos coordenados se representan tres rectángulos creados por cuatro puntos cada
uno (ver Figura 2.15 b):
El plano XY utiliza los puntos (1000, 1000,0), (-1000,1000,0), (-1000,-1000,0) y (1000,-1000,0)
El plano YZ utiliza los puntos (0, 1000,1000), (0,-1000,1000), (0,-1000,-1000) y (0, 1000,-1000)
El plano XZ utiliza los puntos (1000, 0,1000), (-1000, 0,1000), (-1000,0,-1000) y (1000,0, -1000)
Figura 2.15 Representación de un sistema en isométrico utilizando Direct3D
45
2.9 Solución de los ejercicios de representación
Las representaciones de los modelos puntos, rectas y planos se realizan siguiendo los pasos definidos en
los libros de texto de Geometría Descriptiva. Lo diferente de este tipo de ejercicio es la utilización del
Control de Explicación que permite la reproducción paso a paso con su respectiva explicación leída desde
un fichero XML18. Para ello la clase ControlDeExplicación manipula la vista en abatimiento
estableciendo un límite para la cantidad de ayudantes que debe ejecutar. Para que una vista pueda ser
controlada por esta clase debe implementar la interfaz IReproducible. En la Figura 2.16 se muestra el
diagrama de bloques del algoritmo ejecutado como respuesta al evento OnPaint de la vista y en la Figura
2.17 se muestra el diagrama de clases del diseño que representan la relación entre las clases
ControlDeExplicación y D3DAbatimiento.
Para guardar las explicaciones se utilizó el lenguaje XML por la capacidad que tiene de ser validado por
un Schema19 o DTD20, permitiendo que el control de explicaciones se deshabilite en caso de intentar
cargar un fichero de explicación corrupto, lo cual evita el mal funcionamiento de la aplicación. Esto
contribuye a la robustez del sistema.
18 XML (Extensible Markup Language): Es un metalenguaje extensible de etiquetas desarrollado por el World Wide
Web Consortium (W3C). Define una sintaxis genérica para la definición de datos con etiquetas humanamente legibles. Provee un formato estándar para documentos de computadoras, que es lo suficientemente flexible para ser utilizados por dominios tan diferentes como la web, el intercambio electrónico de datos, gráficos vectoriales, serialización de objetos, llamadas a procedimientos remotos y más.
19 XML Schema es un lenguaje de esquema utilizado para describir la estructura y las restricciones de los contenidos
de los documentos XML de una forma muy precisa, más allá de las normas sintácticas impuestas por el propio lenguaje XML. Se consigue así una percepción del tipo de documento con un nivel alto de abstracción. Fue desarrollado por el World Wide Web Consortium (W3C) y alcanzó el nivel de recomendación en mayo de 2001.
20 DTD (Document Type Definition): La definición de tipo de documento es una descripción de estructura y sintaxis de
un documento XML. Su función básica es la descripción del formato de datos, para mantener la consistencia entre todos los documentos que utilicen la misma DTD. De esta forma, dichos documentos se pueden validar, se puede conocer la estructura de sus elementos y la descripción de los datos que trae consigo cada documento. Además, pueden compartir la misma descripción y forma de validación dentro de un grupo de trabajo que usa el mismo tipo de información. Las DTD proporcionan una menor potencia expresiva que los Schemas.
46
Figura 2.16 Diagrama de bloques del algoritmo Representar ejecutado por la vista en abatimiento
Figura 2.17 Diagrama de clases del diseño que representan la relación entre las clases ControlDeExplicación y
D3DAbatimiento.
Limpiar la vista
¿Vista en modo
interactivo?
Configurar la cámara
Representar el sistema de coordenadas
Ejecutar hasta la cantidad de ayudantes
establecidos por el Control de Explicación
Ejecutar todos los ayudantes
No
Si
47
2.10 Solución de los ejercicios de pertenencia, paralelismo e intersecciones
Para la solución del resto de los ejercicios de la aplicación se desarrolló una librería de Geometría
Analítica que es utilizada junto a la teoría de Geometría Descriptiva. El cálculo de la solución de cada tipo
de ejercicio está contenido en una función la cual es registrada como manejadora del evento OnUpdate
del controlador. Esto permite ejecutar la lógica del ejercicio cada vez que el usuario modifica un modelo
geométrico. Las ecuaciones de dicha librería tienen en cuenta los errores numéricos introducidos al
trabajar con números reales. Para ello se utilizó la fórmula del error absoluto. En la Figura 2.18 se
presentan las actividades a realizar para resolver un ejercicio y en la Figura 2.19 se muestra el diagrama
de clases del diseño donde se representa la clase GAnalítica que constituye la librería de Geometría
Analítica.
Figura 2.18 Diagrama de actividades para revolver un ejercicio de pertenencia, paralelismo o intersecciones
Para ejemplificar el diagrama de actividades, veamos el ejercicio de intersección de una recta con un
plano. El usuario introduce los parámetros para la creación de la recta y el plano. El programa comprueba
si existe intersección entre estos modelos. Supongamos que no la hay. El programa representa el ejercicio
dónde se aprecia que no existe intersección. El usuario modifica la posición de la recta. Esta vez sí existe
intersección. El programa cambia el color de la recta y agrega un nuevo modelo para representar el punto
de intersección. El programa representa el ejercicio dónde se aprecia que la recta atraviesa el plano. Por
último, el usuario no desea probar otras variantes y se llega al final del ejercicio.
48
Figura 2.19 Diagrama de clase de la librería de Geometría Analítica
2.11 Extensibilidad, Mantenimiento y reutilización
El diseño de esta aplicación está concebido para ser altamente extensible, fácil de mantener y reutilizable.
Todo gracias a la utilización de los patrones de diseño.
Extensibilidad
En la Figura 2.20 se muestra las cuatros formas de extender el diseño de la aplicación.
Figura 2.20 Las cuatro formas de extender la aplicación
Vistas
(Direct3D)
Controlador
(Modifica un punto a la vez)
Modelos
(Punto, Recta, Plano)
Nuevas vistas que representan los modelos de nuevas formas
Nuevas vistas que utilizan otras
API gráficas (OpenGL, GDI+…)
Nuevos modelos
(Circulo, Prisma,…)
Nuevos controladores
(Modifican los modelos de otra forma)
1
2
3 4
49
Debido a la alta independencia entre las vistas y los modelos es posible extender fácilmente la aplicación.
Para incorporar un modelo nuevo cuya representación esté basada en puntos y rectas sólo se necesita
implementar la interfaz IModelo y hacer “consciente” a las clases que implementa el patrón Simple
Factory, ya sea decorando la clase o sustituyéndola por otra, que reconozcan el nuevo modelo
geométrico. Un ejemplo de este modelo sería un prisma de base rectangular. Si el nuevo modelo no está
constituido por modelos ya existentes se debe crear dichos modelos y soportar la creación del nuevo
elemento en la clase que implementa el patrón Factory Method. Un ejemplo de esto es el cono, pues para
su representación las vistas necesitan saber dibujar un círculo, por tanto habría que crear la clase
CírculoModel y la clase ayudante D3DHLCírculo. Esta última sabe cómo representar el nuevo modelo
usando Direct3D. Además, hay que decorar D3DLowFactory o crear una subclase de
D3DFactoryMethod que instancie una clase D3DCírculo cuando reciba como parámetro una instancia
de la clase CírculoModel. En la Figura 2.21 se presenta el diagrama de clases donde se agrega el
modelo CírculoModel, por lo tanto se utiliza AbatimientoSimpleFactory2,
IsométricoSimpleFactory2 y D3DLowFactory2 que agregan el “conocimiento” sobre el nuevo
modelo.
50
Figura 2.21 Diagrama de clases que representa la extensión de la aplicación al agregar un nuevo modelo
También es posible extender la aplicación desde la parte de las vistas en el patrón MVC de dos maneras:
1. Creando nuevas vistas que utilicen otras APIs gráfica como OpenGL.
2. Creando nuevas vistas que representen los modelos de otra forma.
51
3. Para incorporar una vista en abatimiento usando OpenGL se necesita construir un control de
usuario que implemente la interfaz IVista y que encapsule el trabajo con la inicialización, la
configuración de la cámara y la visualización. También se debe crear las clases ayudantes que
representen los modelos mediante el uso de OpenGL (GLHLPunto,GLHLRecta y GLPlano) y la
clase GLLowFactory que herede de la clase abstracta GLFactoryMethod. Esta última debe ser
capaz de devolver la instancia de las clases ayudantes que representen a los modelos pasados
como parámetro. En la Figura 2.22 se muestra el diagrama de clase que contiene dos vistas en
abatimiento, la primera utiliza Direct3D y la segunda OpenGL.
Figura 2.22 Diagrama de clases que representa la extensión de la aplicación al agregar una vista en abatimiento que utiliza la API gráfica OpenGL.
52
Para construir una vista que represente los modelos de otra forma (por ejemplo en un sistema de
coordenadas polares pero usando Direct3D), se necesita desarrollar un control de usuario con la
configuración de la cámara correspondiente y crear la clase que implemente el patrón Simple Factory, de
forma tal que sepa fabricar todos los modelos auxiliares a ser representados. En la Figura 2.23 se muestra
el diagrama de clases que muestra una vista en abatimiento y otra en coordenadas polares.
Figura 2.23 Diagrama de clases que representa la extensión de la aplicación al agregar una nueva vista que presentan los modelos en coordenadas polares.
53
Mantenimiento
El uso de los patrones trae como consecuencia una alta cohesión y un bajo acoplamiento entre las clases,
lo que hace el mantenimiento más sencillo, ya que los cambios realizados en una clase tienen poca
repercusión en el resto de las clases de la aplicación.
Reutilización
Se puede utilizar las clases que conforman el MVC en otra aplicación sin tener que adquirir conocimientos
del trabajo con DirectX. En un programa que grafique funciones matemáticas se puede reutilizar toda la
arquitectura y construir una vista que represente un sistema cartesiano. También se puede reutilizar la
librería de ecuaciones de Geometría Analítica, así como el control de explicación para controlar la
reproducción de cualquier otra clase que implemente la interfaz IReproducible.
En la Figura 2.22 se aprecia cómo dos vistas que utilizan diferentes API gráficas pero representan un
sistema en abatimiento reutilizan la clase AbatimientoSimpleFactory para obtener los modelos
auxiliares.
En la Figura 2.23 se aprecia cómo dos vistas que utilizan Direct3D y que representan los modelos en
abatimiento y en un sistema de coordenadas polares, reutilizan la clase D3DLowFactory para crear las
clases ayudantes.
2.12 Elementos del estilo de códigos
Durante la codificación de la aplicación se utilizó el idioma español. No obstante, debido al uso de la
tecnología y patrones de diseño empleados se determinó el uso de tecnicismos en inglés en algunos
nombres de clases. Los nombres de las variables y parámetros de las funciones empiezan con minúscula.
En caso de existir un nombre compuesto, las palabras se escriben a continuación una de la otra, pero a
diferencia de la primera, todas empiezan con mayúscula. Los nombres de las clases y funciones
comienzan con mayúscula y cumplen con la misma regla para el uso de nombres compuestos. Se utiliza
una línea propia para el inicio de llaves y otra para el cierre, facilitando la comprensión del código fuente.
Las clases que denotan los modelos utilizados en el patrón MVC y representan el patrón Simple Factory o
Factory Method terminan con el sufijo –Model, -SimpleFactory o –FactoryMethod respectivamente. Las
clases que utilizan la API gráfica Direct3D comienzan con el prefijo D3D. En caso de extenderse la
54
aplicación con clases que utilicen OpenGL se recomienda seguir esta misma regla utilizando el prefijo GL.
Las interfaces siguen el estilo establecido por Microsoft y utilizan el prefijo i.
2.13 Conclusiones del capítulo
El patrón MVC constituye el núcleo de la aplicación. Los patrones Simple Factory y Factory Method liberan
a las vistas de ser responsables de la creación de los modelos auxiliares y de las clases ayudantes que
dibujan dichos modelos. El trabajo con la API gráfica Direct3D permitió la creación de dos vistas que
representan un sistema en abatimiento y un sistema en isométrico. También se demostró cómo los
patrones de diseño logran una mayor extensibilidad y reusabilidad, los cual contribuye al mantenimiento
del software.
.
55
Capítulo 3: Pruebas realizadas y resultados obtenidos
3.1 Introducción al capítulo
En el presente capítulo se aborda el estudio de factibilidad del proyecto, el cuál está basado en el modelo
de estimación de costos COCOMO II. Se describen las técnicas de pruebas aplicadas y se presentan los
diseños de casos de pruebas utilizando técnicas de pruebas de caja blanca y caja negra. Además se
realiza un análisis de los resultados obtenidos y se refleja el criterio de los especialistas.
3.2 Estudio de Factibilidad
Esta investigación es un ejercicio obligatorio para optar por el título de Ingeniero Informático, debido a esto
en su comienzo no fue necesaria la realización de un estudio de factibilidad. Por esta razón el estudio de
factibilidad presentado en este epígrafe constituye un recurso para estimar a posteriori, el tiempo, el costo
y la cantidad de personal necesario en el desarrollo de una herramienta computacional de este tipo.
3.2.1 Estimación de costos del proyecto de software
Antes de dar luz verde al proyecto de software se debe efectuar un estudio de factibilidad para estimar los
costos y comprobar si es viable su realización. Para llevar a cabo dicho estudio se utilizó COCOMO II.
En(20), Moreno define COCOMO II (Constructive Cost Model II) como un modelo que permite estimar el
costo, esfuerzo y tiempo cuando se planifica una nueva actividad de desarrollo software.
La familia de modelos COCOMO II está compuesta por tres sub-modelos cada uno de los cuales ofrece
mayor fidelidad a medida que se avanza en la planificación del proyecto y en el proceso de diseño. Unos
de los tres sub-modelos es el modelo de Composición de Aplicaciones, indicado para proyectos
construidos con herramientas modernas de desarrollo de interfaces gráficas para usuarios(20). La
herramienta “Suite de Geometría Descriptiva” se encuentra en esta categoría, por lo que la estimación se
basa en PO21 (Puntos Objeto).
A continuación se presentan los pasos para lograr la estimación de los costos utilizando el modelo de
Composición de Aplicaciones.
21
PO. Los Puntos Objeto son el recuento de pantallas, informes y módulos de lenguajes de 3ra generación desarrollados en la
aplicación, cada uno ponderado mediante un factor de complejidad de tres niveles: simple, medio y complejo.
56
Paso 1. Recuento de objetos.
En este paso se estima el número de pantallas, informes y componentes de las que consta la aplicación.
Al estudiar la herramienta, se identificaron once pantallas y tres componentes, lo que hace un total de
trece objetos.
Paso 2: Clasificar cada instancia de objeto dentro de niveles de complejidad simple, media y difícil.
La complejidad de los objetos identificados en el paso 1 se clasifica usando la tabla 7.3 en (20), en simple,
media y difícil.
Paso 3: Pesar la complejidad de los objetos identificados.
La complejidad de los objetos identificados en el paso 1 se pesa usando la tabla 7.4 en (20). En la Tabla
3.1 se muestran los objetos identificados en la aplicación con su respectiva complejidad y peso asociado.
Tabla 3.1 Objetos identificados en la aplicación
Objeto Clasificación Complejidad Peso
Ventana principal Pantalla Simple 1
Ventana de ejercicios de representación de puntos Pantalla Difícil 3
Ventana de ejercicios de representación de rectas Pantalla Difícil 3
Ventana de ejercicios de representación de planos Pantalla Difícil 3
Ventana de ejercicios de pertenencia de un punto a una recta Pantalla Difícil 3
Ventana de ejercicios de pertenencia de una recta a un plano Pantalla Difícil 3
Ventana de ejercicios de pertenencia de un punto a un plano Pantalla Difícil 3
Ventana de ejercicios de paralelismo entre dos rectas Pantalla Difícil 3
Ventana de ejercicios de paralelismo entre una recta y un plano Pantalla Difícil 3
Ventana de ejercicios de intersección entre dos rectas Pantalla Difícil 3
Ventana de ejercicios de intersección entre una recta y un plano Pantalla Difícil 3
Vista en abatimiento Componente Difícil 10
Vista en isométrico Componente Difícil 10
Control de explicación Componente Difícil 10
57
Paso 4: Determinar Puntos Objeto
En este paso se suman todos los pesos de los objetos identificados para determinar Puntos Objeto (PO).
PO = 1 * 1 + 10 * 3 + 3 * 10 = 61
Paso 5: Estimar el porcentaje de reutilización que se espera lograr en este proyecto y calcular los Nuevos
Puntos Objeto a desarrollar.
NOP: Nuevos Puntos Objeto: Cantidad de Puntos Objeto ajustados por la reutilización.
%reuse: Porcentaje de pantallas, informes y módulos 3GL22 reutilizados a partir de aplicaciones anteriores
aproximadas por grado de reutilización
Se estima que la utilización de la plataforma .Net y el uso de la API gráfica Direct3D introduce un 30% de
reutilización de código.
Luego utilizando la Ecuación 3.1 se determina el valor de NOP
Ecuación 3.1: Cálculo de NOP
Paso 6: Determinar la proporción de productividad (PROD)
La proporción de productividad se determina a partir de la tabla 7.5 definida en (20).
PROD = 7.
Paso 7: Calcular el valor Meses-Persona (MM)
El valor de Meses-Persona se estima utilizando la Ecuación 3.2.
Ecuación 3.2: Cálculo de Meses-Persona
22 3GL. Lenguajes de tercera generación.
58
Paso 8: Calcular el costo monetario del proyecto:
Para calcular el costo monetario del proyecto se utiliza la Ecuación 3.3, donde CH es la cantidad de
hombres y SM es el salario mensual por persona. Si se considera que el valor de SM es $400 y CH es 1,
el costo es de $2,440.
Ecuación 3.3: Cálculo del costo
3.2.3 Beneficios Tangibles e Intangibles.
Los beneficios tangibles que ofrece el software Suite de Geometría Descriptiva se aprecian una vez que
los estudiantes comiencen a utilizarlo para comprobar la solución de los ejercicios orientados en las clases
prácticas de la asignatura y representen variantes que no aparecen en los materiales de estudio. También
pueden aprender la metodología de resolución de los ejercicios. Por otra parte, los profesores pueden
utilizar la herramienta en las conferencias y clases prácticas
Como beneficio intangible se puede mencionar el aumento de la percepción del estudiante de las
representaciones de los modelos geométricos en el plano y en el espacio.
3.3 Técnicas de pruebas
Existen diferentes técnicas y niveles de pruebas que pueden aplicarse durante el proceso de desarrollo de
un sistema. A continuación se describen las más utilizadas.(21)
Prueba de Regresión: verifica el sistema luego de haber efectuado cambios, por ejemplo después
de corregir una falta, de manera que se mantenga la funcionalidad especificada originalmente.
Prueba de Operación: verifica el sistema en operación por un período largo de tiempo bajo
condiciones normales de uso. Este tipo de prueba mide la confiabilidad del sistema.
Prueba de Escala Completa: verifica el sistema en su carga máxima asignando los parámetros a
su valor límite, interconectando el sistema con un máximo de equipos y usuarios simultáneos. Un
extremo de esto es la prueba de estrés que significa que se ejecuta el sistema en sus límites
extremos para ver qué tanto soporta y si ocurre algún tipo de falla.
Prueba de Rendimiento o Prueba de Capacidad: mide la capacidad de procesamiento del
sistema bajo diferentes cargas, incluyendo el espacio de almacenamiento y utilización del CPU.
Los valores medidos se comparan con los valores requeridos.
59
Prueba de Sobrecarga: analiza cómo se comporta el sistema cuando se le aplica una sobrecarga,
más allá de las pruebas de escala completa y rendimiento. Aunque no se puede esperar que el
sistema soporte estas pruebas, este debería ejecutarse correctamente, sobrevivir picos de carga,
evitando que ocurra una catástrofe. Es siempre importante saber en qué momento y de qué
manera cae el rendimiento del sistema.
Prueba Negativa: mide el estrés del sistema en situaciones inesperadas, como en casos de uso
que normalmente no serían invocados simultáneamente. El sistema se usa intencionalmente y
sistemáticamente de manera incorrecta. Este maltrato debe ser cuidadosamente planeado para
probar aspectos especialmente críticos.
Prueba estructural o Prueba de caja blanca: verifica que la estructura interna de una unidad sea
correcta. Es deseable cubrir todas las posibles combinaciones de parámetros, valores de variables
y flujos en el código, de manera que todas las instrucciones se ejecuten. Para examinar la
efectividad de los casos de prueba se debe medir la cobertura de prueba dónde cada ruta en el
código sea cubierta o probada al menos una vez. La mayoría de los problemas provienen de
combinaciones de rutas inusuales como aquellas que involucran ciclos. Los casos de prueba se
ilustran mediante diagramas de flujo.
Prueba de especificación o Prueba de caja negra: verifica las relaciones de entrada y salida de
una unidad. El objetivo es verificar qué hace la unidad, pero sin saber cómo lo hace. Se envían
estímulos con diferentes parámetros de entrada y se comparan las salidas esperadas. Dado que
las unidades se comunican mediante interfaces bien definidas, la prueba de especificación es
bastante directa.
Pruebas Ergonómicas: comprueba los aspectos ergonómicos del sistema, en otras palabras, las
interfaces hombre-máquina en el caso de que estas existan. Por ejemplo, se prueba si las
interfaces son consistentes con los casos de uso a los cuales corresponden, si los menús son
lógicos y legibles, si los mensajes del sistema son visibles, si se puede entender los mensajes de
errores, etc.
Prueba de Documentación de Usuario: comprueba la documentación de usuario, incluyendo el
manual de usuario y documentación de mantenimiento y servicio. Se prueba que los manuales y
comportamiento del sistema sean consistentes entre sí, legibles y comprensibles.
Prueba de Aceptación o Prueba de Validación: logra una revisión final por parte de la
organización que solicitó el sistema, siendo esto a menudo la validación del sistema. El sistema se
60
prueba en su ambiente real por un período largo de tiempo. Cuando se termina la prueba se
decide si el producto se acepta o no. Este tipo de prueba es a veces conocida como prueba alfa. Si
no existe un cliente particular que haya solicitado el sistema, por ejemplo en el caso de un
producto de software de venta al público, a menudo se hace una prueba beta. Esto significa que
antes de enviarlo al público en general, el producto es probado por clientes seleccionados que
utilizan el sistema y reportan fallas experimentadas.
Por las características de la aplicación construida las pruebas de Operación, Escala Completa,
Rendimiento y Sobrecarga no son tomadas en cuenta. Dichas pruebas se aplican a programas complejos,
que consumen gran cantidad de recursos y soportan varios usuarios simultáneamente. Las pruebas de
Regresión tampoco son ejecutadas por no realizarse cambios importantes, ya que el uso de los patrones
brinda un diseño validado y bien estructurado. No fue posible la realización de la Prueba de Aceptación o
Prueba de Validación, ya que dicha prueba requiere que el sistema se pruebe en su ambiente real y por
un largo período de tiempo. En su lugar se hicieron pequeñas pruebas con profesores de la asignatura
Geometría Descriptiva y con estudiantes de primer año de Ingeniería Mecánica en una clase de
laboratorio.
Las pruebas Ergonómicas y Documentación de Usuario se realizaron rápidamente por la gran facilidad de
uso del programa que brinda su sencilla interfaz de usuario. La documentación fue comprobada por los
especialistas y se realizaron pruebas a la interfaz para comprobar la satisfacción de los requisitos
funcionales, el correcto uso de los colores y la utilización del espacio.
3.3.1 Pruebas de caja blanca
La prueba de caja blanca es un método de diseño de casos de prueba que usa la estructura de control del
diseño procedimental para obtener los casos de prueba. Mediante los métodos de prueba de caja blanca,
el ingeniero del software puede obtener casos de prueba que garanticen que se ejercite al menos una vez
todos los caminos independientes de cada módulo, la ejecución de todas las decisiones lógicas en sus
vertientes verdadera y falsa, así como todos los bucles con sus límites operacionales. Además se
chequean las estructuras internas de datos para asegurar su validez. (22)
Las pruebas exhaustivas no son factibles debido a que el número de caminos, incluso para un programa
de tamaño moderado, es excepcionalmente grande. Sin embargo, la prueba de caja blanca no se debe
61
desechar, ya que se puede elegir y ejercitar una serie de caminos lógicos importantes, al igual que se
puede comprobar la validez de las principales estructuras de datos.
En este trabajo de diploma se utilizó la prueba del camino básico. Esta es una técnica de prueba de caja
blanca que permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un
diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos
de ejecución. En (22), Pressman define la complejidad ciclomática como el número de caminos
independientes del conjunto básico de un programa, que determina el número superior de pruebas que se
deben hacer para asegurar que se ejecute cada sentencia al menos una vez.
El método de prueba de camino básico se puede aplicar a un diseño procedimental detallado o a un
código fuente. A continuación se presenta la aplicación de esta técnica paso a paso sobre el código que
resuelve el problema de pertenencia de un punto a una recta desde el punto de vista de la Geometría
Descriptiva.
private void controlador_OnUpdate (Busqueda resultado)
{
RectaModel recta = (RectaModel)resultado.Ejercicio.Modelo(“AB”); [1]
if (!resultado.Ejercicio.Iteractivo) [2]
{
PuntoModel p = Matemática.PuntoMedio(recta);
p.Nombre = “P”;
p.Color = Color.Yellow;
richTextBox2.Text = “El punto P pertenece a la recta AB [3]
ya que sus trazas se encuentran sobre las trazas de la
recta.”;
resultado.Ejercicio.Agregar(p);
}
else
{
bool h = false, f = false, l = false;
PuntoModel p = (PuntoModel)resultado.Ejercicio.Modelo(“P”);
62
IModelo[] trazasRecta = AbatimientoSimpleFactory.TrazasRecta(recta); [4]
PuntoModel[] trazasPunto = AbatimientoSimpleFactory.TrazasPunto(p);
if (trazasRecta[0] is RectaModel) [5]
h = Matemática.PerteneceAcotado(trazasPunto[0], ¬
(RectaModel)trazasRecta[0]); [6]
else
h = ((PuntoModel)trazasRecta[0]).Aproximado(trazasPunto[0]); [7]
if (trazasRecta[1] is RectaModel) [8]
f = Matemática.PerteneceAcotado(trazasPunto[1], ¬
(RectaModel)trazasRecta[1]); [9]
else
f = ((PuntoModel)trazasRecta[1]).Aproximado(trazasPunto[1]); [10]
if (trazasRecta[2] is RectaModel) [11]
l = Matemática.PerteneceAcotado(trazasPunto[2], ¬
(RectaModel)trazasRecta[2]); [12]
else
l = ((PuntoModel)trazasRecta[2]).Aproximado(trazasPunto[2]); [13]
if (h && f && l ) [14,15,16]
{
richTextBox2.Text = “El punto P pertenece a la recta AB ya
que sus trazas se encuentran sobre las trazas de la recta.”; [17]
p.Color = Color.Yellow;
}
else
{
richTextBox2.Text = “El punto P no pertenece a la
recta AB porque sus trazas no se encuentran sobre [18]
las trazas de la recta.”;
p.Color = Color.Black;
63
}
} [19]
}
Este código comprueba si el ejercicio se encuentra en modo interactivo. De ser así cada vez que el
usuario modifique la posición de la recta o del punto, se verifica si el punto pertenece a la recta. Para ello
se determina si la proyección del punto se encuentra sobre la traza de la recta en su correspondiente
plano horizontal, frontal y lateral. Si el ejercicio no se encuentra en modo interactivo, sólo hay que mostrar
un punto que pertenezca a la recta, siendo el punto medio de la recta la solución más directa.
Paso 1: Usando el código como base, se dibuja el correspondiente grafo de flujo.
64
Figura 3.1 Grafo de flujo para el código de la función llamada por el evento OnUpdate del controlador del ejercicio de pertenencia
de un punto a una recta.
Región 6
Región 7
1
2
3 4
5
6 7
8
9 10
11
12 13
14
15
16
17 18
19
Región 1
Región 3
Región 4
Región 2
Región 5
Región 8
65
Paso 2: Calcular la complejidad ciclomática para determinar el límite superior para el número de
caminos independientes que componen el conjunto básico.
La complejidad ciclomática está basada en la teoría de grafos y da una métrica del software
extremadamente útil. En (22), Pressman describe tres formas de calcularla:
1. El número de regiones del grafo de flujo coincide
2. La complejidad ciclomática, V(G), de un grafo de flujo se define como V(G)=A-N+2 donde A es el
número de aristas del grafo de flujo y N es el número de nodos del mismo.
3. La complejidad ciclomática, V(G), de un grafo de flujo G también se define como V (G)=P+ 1 donde
P es el número de nodos predicado contenidos en el grafo de flujo G.
Refiriéndonos al grafo de flujo de la Figura 3.1, la complejidad ciclomática se puede calcular mediante
cualquiera de las tres formas anteriores:
1. El grafo de flujo tiene ocho regiones
2. V(G) = 25 aristas - 19 nodos + 2 = 8
3. V(G) = 7 nodos predicado + 1 = 8.
Por consiguiente queda demostrado que el número de caminos independientes a determinar son ocho.
Paso 3: Determinar un conjunto básico de caminos linealmente independientes.
En el paso anterior se determinó que se deben especificar ocho caminos:
Camino 1: 1-2-3-19
Camino 2: 1-2-4-5-6-8-9-11-12-14-15-16-17-19
Camino 3: 1-2-4-5-7-8-9-11-12-14-15-16-17-19
Camino 4: 1-2-4-5-6-8-10-11-12-14-15-16-17-19
Camino 5: 1-2-4-5-6-8-9-11-13-14-15-16-17-19
Camino 6: 1-2-4-5-6-8-9-11-12-14-18-19
Camino 7: 1-2-4-5-6-8-9-11-12-14-15-18-19
Camino 8: 1-2-4-5-6-8-9-11-12-14-15-16-18-19
66
Paso 4: Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto
básico.
Para poder ejecutar los casos de prueba se deben escoger la recta y el punto, de forma tal que las
condiciones de los nodos predicados estén adecuadamente establecidas, con el fin de comprobar cada
camino. Los casos de prueba que satisfacen el conjunto básico previamente descrito son los siguientes:
Caso de prueba del camino 1:
Se selecciona la variante del ejercicio en que el programa encuentra un punto que pertenezca a la recta
dada.
Resultado esperado: El programa muestra la representación de la recta y de un punto perteneciendo a la
misma en las dos vistas y la explicación de por qué se cumple la condición de pertenencia según la teoría
de Geometría Descriptiva. El punto se representa de color amarillo.
Caso de prueba del camino 2:
Se selecciona la variante interactiva del ejercicio que permite el cambio de posición de cualquiera de los
dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que pertenezca a la
misma. La recta debe ser oblicua para que sus proyecciones en el plano horizontal, frontal y lateral sean
una recta.
Resultado esperado: El programa muestra la representación de la recta y del punto perteneciendo a la
misma en las dos vistas y la explicación de por qué se cumple la condición de pertenencia según la teoría
de Geometría Descriptiva. El punto se representa de color amarillo.
Caso de prueba del camino 3:
Se selecciona la variante interactiva del ejercicio que permite el cambio de posición de cualquiera de los
dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que pertenezca a la
misma. La recta debe ser perpendicular al plano horizontal para que su proyección en dicho plano sea un
punto.
67
Resultado esperado: El programa muestra la representación de la recta y del punto que le pertenece en
las dos vistas y la explicación de por qué se cumple la condición de pertenencia según la teoría de
Geometría Descriptiva. El punto se representa de color amarillo.
Caso de prueba del camino 4:
Se selecciona la variante interactiva del ejercicio que permite el cambio de posición de cualquiera de los
dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que pertenezca a la
misma. La recta debe ser perpendicular al plano frontal para que su proyección en dicho plano sea un
punto.
Resultado esperado: El programa muestra la representación de la recta y del punto que le pertenece en
las dos vistas y la explicación de por qué se cumple la condición de pertenencia según la teoría de
Geometría Descriptiva. El punto se representa de color amarillo.
Caso de prueba del camino 5:
Se selecciona la variante interactiva del ejercicio que permite el cambio de posición de cualquiera de los
dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que le pertenezca. La
recta debe ser perpendicular al plano lateral para que su proyección en el dicho plano sea un punto.
Resultado esperado: El programa muestra la representación de la recta y del punto que le pertenece en
las dos vistas y la explicación de por qué se cumple la condición de pertenencia según la teoría de
Geometría Descriptiva. El punto se representa de color amarillo.
Caso de prueba del camino 6:
Se selecciona la variante interactiva del ejercicio que permite el cambio de posición de cualquiera de los
dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que no le pertenezca.
Las proyecciones del punto deben encontrase en las proyecciones de la recta en el plano frontal y lateral,
no siendo el caso en el plano horizontal.
68
Resultado esperado: El programa muestra la representación de la recta y el punto. Se aprecia y explica
por qué no se cumple la condición de pertenencia según la teoría de Geometría Descriptiva. El punto no
cambia de color.
Caso de prueba del camino 7:
Se selecciona la variante interactiva del ejercicio el cual permite el cambio de posición de cualquiera de
los dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que no le pertenezca.
Las proyecciones del punto deben encontrase en las proyecciones de la recta en el plano horizontal y
lateral, no siendo el caso en el plano frontal.
Resultado esperado: El programa muestra la representación de la recta y del punto perteneciente. Se
aprecia y explica por qué no se cumple la condición de pertenencia según la teoría de Geometría
Descriptiva. El punto no cambia de color.
Caso de prueba del camino 8:
Se selecciona la variante interactiva del ejercicio que permite el cambio de posición de cualquiera de los
dos modelos geométricos utilizando el mouse. Se introduce una recta y un punto que no le pertenezca.
Las proyecciones del punto deben encontrase en las proyecciones de la recta en el plano horizontal y
frontal, no siendo el caso en el plano lateral.
Resultado esperado: El programa muestra la representación de la recta y del punto. Se aprecia y explica
por qué no se cumple la condición de pertenencia según la teoría de Geometría Descriptiva. El punto no
cambia de color.
3.3.2 Pruebas de caja negra
Las pruebas de caja negra se enfocan en la validación del comportamiento de la aplicación, o sea, se
deben encontrar las discrepancias entre lo que el programa hace y lo que debería hacer. Esta técnica de
prueba y la técnica de prueba de caja blanca no son mutuamente excluyentes, sino que se complementan
entre sí.
Para determinar los casos de prueba se utilizó el método de partición equivalente. Este método consiste
en la identificación de clases de equivalencias tanto para la entrada de datos válidos, como los no válidos
69
o erróneos. Luego, se crean casos de pruebas que cubran tantas clases válidas no utilizadas en otros
casos previamente. Lo mismo ocurre para las clases no válidas. Esto permite comprobar la funcionalidad
del software analizando el dominio de valores de entrada. En la Tabla 3.2 se especifican las clases de
equivalencias utilizadas en los casos de pruebas.
Tabla 3.2 Clases de equivalencias
Entrada Clases validas Clases invalidas
Coordenadas de un
punto
(1) X >= 0, Y>= 0, Z>=0) (2) X < 0, Y< 0, Z>0
(3) X, Y o Z no es un numero
Coordenadas de un
segmento de recta
(4) Punto 1 ≠ Punto 2
(5) X1 >= 0, Y1>= 0, Z1>=0
X2 >= 0, Y2>= 0, Z2>=0
(6) Punto 1 = Punto 2
(7) X1 < 0, Y1 < 0, Z1 < 0
X2 < 0, Y2 < 0, Z2 < 0
Coordenadas de un
triangulo que define un
plano
(8) Los tres puntos no son colineales
(9) Punto1 ≠ Punto 2
(10) Punto 2 ≠ Punto3
(11) Punto 1 ≠ Punto3
(12) X1 >= 0, Y1>= 0, Z1>=0
X2>= 0, Y2>= 0, Z2>=0
X3>= 0, Y3>= 0, Z3>=0
Los tres puntos son colineales
(13) Punto 1 = Punto 2
(14) Punto 2 = Punto 3
(15) Punto 1= Punto 3
(16) X1 < 0, Y1< 0, Z1< 0
X2< 0, Y2< 0, Z2< 0
(17) X3< 0, Y3< 0, Z3< 0
Un beneficio importante de los casos de prueba de caja negra es señalar las debilidades y carencias de
las especificaciones del programa.(23)
Los casos de pruebas de caja negra fueron ejecutados por dos grupos de estudiantes de primer año de
Ingeniería Mecánica en una clase de laboratorio.
3.4 Análisis de los resultados obtenidos
El resultado de esta investigación es la creación de una herramienta computacional usada como
complemento de la asignatura Geometría Descriptiva en las carreras de ingeniería en la UMCC. Dicha
herramienta actúa como resolvedor de los ejercicios orientados en las clases prácticas, permitiendo al
70
estudiante comprobar si su solución es correcta, aprender la teoría y los pasos de la solución de los
ejercicios. Este software tiene soporte para diez tipos de ejercicios (Ver anexos del 13 al 22):
Representación del punto.
Representación de la recta.
Representación del plano.
Pertenencia de un punto a una recta.
Pertenencia de una recta a un plano.
Pertenencia de un punto a un plano.
Paralelismo entre dos rectas.
Paralelismo entre una recta y un plano.
Intersección entre dos rectas.
Intersección entre una recta y un plano.
Para la validación de la investigación se realizó un pequeño experimento con dos grupos de estudiantes
de primer año de Ingeniería Mecánica (45 estudiantes en total). Se seleccionaron del cuaderno dos
ejercicios de cada tipo soportados por la aplicación. El 95.6 % de los alumnos pudieron obtener la solución
con su respectiva explicación y representación en el plano y en el espacio. El 4.4% restante presentó
dificultades con la comprensión de algunos ejercicios. Además los alumnos expresaron que la herramienta
los ayuda a adquirir una mejor visión de los modelos en la proyección isométrica y en la representación en
abatimiento.
3.5 Criterios de los especialistas
Para el desarrollo y la validación de la herramienta computacional “Suite de Geometría Descriptiva” se
consultaron profesores de la UMCC que imparten dicha asignatura:
MSc. Antonio Celso Fernández Orquín: Profesor Auxiliar de la asignatura Gráficos por
Computadoras y jefe del grupo de software “Anubis” de la Facultad de Ingeniería Informática.
Dr. Ramón Quiza: Jefe de Computación de la Facultad de Ingeniería Mecánica.
Prof. Ing. Juan Manuel Rodríguez: Profesor de las asignaturas Dibujo Técnico y Geometría
Descriptiva de la Facultada de Ingeniería Mecánica.
71
Prof. Lic. Adolfo Torres: Profesor de la asignatura Geometría Descriptiva de la Facultad de
Ingeniería Mecánica.
Prof. Arq. Maurys Alfonso Risco: Profesor de la asignatura Geometría Descriptiva de la Facultad de
Ingeniería Civil.
Los especialistas contribuyeron con el enriquecimiento de los conocimientos teóricos sobre la materia.
Aportaron ideas de cómo debe ser organizada la interfaz, según el grado de dificultad de los ejercicios
comprendidos en el campo de acción. Además, describieron las características que debía tener la
aplicación para poder ser utilizada en el estudio de la Geometría Descriptiva. Una vez finalizada la
construcción del software procedieron a su validación, concluyendo que el programa se desempeña
correctamente al resolver, representar y explicar la solución de los ejercicios. También decidieron emplear
la herramienta en las clases de dicha asignatura a partir del próximo curso escolar
3.6 Documentación del sistema
La documentación del sistema (24) cubre todas las fases del desarrollo del proyecto. En ella se
documentan los artefactos producidos en las disciplinas definidas en la metodología RUP: Modelado del
Negocio, Requisitos, Análisis y Diseño y Despliegue. Se ofrece además, el manual de usuario (25) que
recoge el modo de utilización y los requisitos para la ejecución de la herramienta computacional creada.
La documentación del sistema y el manual de usuario están incluidos en el disco de instalación de la
aplicación.
3.7 Conclusiones del capítulo
En el estudio de factibilidad efectuado se comprueba que la realización de una aplicación de este tipo es
viable. Las técnicas de pruebas realizadas permitieron la comprobación y validación del correcto
funcionamiento de la aplicación. Los especialistas consultados coincidieron en que la herramienta
elaborada complementa el estudio de la Geometría Descriptiva y consideran que los resultados obtenidos
son satisfactorios.
72
Conclusiones generales
Culminada la investigación y después de haber resuelto cada uno de los objetivos trazados el autor
concluye lo siguiente:
Los materiales de estudio utilizados en la asignatura de Geometría Descriptiva de las carreras de
ingeniería de la Universidad de Matanzas “Camilo Cienfuegos” presentan limitaciones en las
representaciones gráficas de los ejercicios. Por otra parte escasean los software relacionados con
el campo de la Geometría Descriptiva y los existentes no cumplen con los requerimientos para ser
implantados como complemento de dicha asignatura.
Para la creación de la herramienta Suite de Geometría Descriptiva se utilizó la API gráfica Direct3D
desde la plataforma .Net.
El uso de los patrones de diseño y las técnicas de análisis y diseño orientado a objetos permitieron
crear una arquitectura flexible y extensible.
La metodología RUP sirvió de guía a lo largo del proceso de desarrollo del proyecto de software.
Las técnicas de pruebas empleadas permitieron la verificación y validación de la aplicación.
Los criterios de los especialistas consultados confirmaron la validez de la herramienta y la
factibilidad de su aplicación como complemento en el estudio de la Geometría Descriptiva.
73
Recomendaciones
Para la continuidad del trabajo se recomienda:
Extender por los estudiantes de informática de otros años el software desarrollado para abarcar
todo el contenido que se imparte en la asignatura de Geometría Descriptiva en las carreras de
ingeniería de la Universidad de Matanzas “Camilo Cienfuegos”.
Expandir los tipos de modelos y crear un conjunto de vistas que representen los modelos de otra
manera para que se pueda reutilizar la arquitectura incluso en otros proyectos que no tengan que
ver con el campo de la Geometría Descriptiva.
Recopilar sugerencias e ideas nuevas por parte de los estudiantes y profesores con el fin de
mejorar el producto para que resulte cada vez más profesional y competitivo.
74
Referencias Bibliográficas
1. Pietro DD. Geometría Descriptiva. Tercera Edición ed.: Editorial Pueblo y Educación; 1988.
2. Padrón I. Procecad. Software de Geometría Descriptiva para Windows.; 2006 [visitada en 2008];
Disponible en: www.procecad.com.
3. Nager AM, Socorro RA, Torres JD. Geometría Descriptiva. Segunda Edición ed.: Editorial Pueblo y
Educación; 1987.
4. MURILLO JI. Nociones Básicas de la Geometría Analítica. Artículo Electrónico. 2002.
5. LEHMANN CH. Geometría Analítica. Limusa; 1989.
6. Schneider PJ, Eberly DH. Geometry Tools for Computer Graphics. Morgan Kaufmann Publishers;
2003.
7. Wooton W, Beckenbach EF, Fleming FJ. Geometria Analítica Moderna. Publicaciones Cultural,
S.A; 1985.
8. Kruchten P. Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Addison
Wesley; 2003.
9. Pollice G. Using the IBM Rational Unified Process for Small Projects: Expanding Upon eXtreme
Programming. IBM; 2003.
10. Jacobson I, Booch G, Rumbaugh J. El Proceso Unificado de Desarrollo de Software. Addison
Wesley; 2000.
11. Pender T. UML Bible. John Wiley & Sons; 2003.
12. Hoxley J. Basic Direct3D 9.0 The Managed Way. Artículo Electrónico. 2003.
13. Miller T. Managed DirectX® 9: Graphics and Game Programming. Sams Publishing; 2003.
14. Wikipedia. 2009 [visitada en 2009]; Disponible en: http://es.wikipedia.org/wiki/Patrón_de_diseño.
15. Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns. Elements of reusable Object-Oriented
Software Addison-Wesley; 2000.
16. Developing with the MVC Pattern. 2009 [visitada en 2009]; Disponible de :
http://msdn.microsoft.com/en-us/library/cc540716.aspx.
17. Shalloway A, Trott JR. Design Patterns Explained. Addison-Wesley; 2003.
75
18. Trowbridge D, Mancini D, Quick D, Hohpe G, Newkirk J, Lavigne D. Enterprise Solution Patterns
Using Microsoft .Net 2.0. Microsoft Press; 2003.
19. Lobao AS, HATTON E. .NET Game Programming with DirectX 9.0. Apress; 2003.
20. Moreno AM. Estimación de Proyectos Software.
21. Weitzenfeld A. Ingeniería de Software Orientada a Objetos.Teoría y Práctica con UML y Java.:
Itam; 2002.
22. Pressman RS. Ingeniería de Software. Un enfoque práctico. Quinta Edición ed.: McGraw Hill; 2002.
23. PezzandMichal M. Software Testing and Analysis: Process, Principles and Techniques. John Wiley
& Sons; 2008.
24. Rodríguez DA. Documentación del Sistema: Suite de Geometría Descriptiva. Universidad de
Matanzas "Camilo Cienfuegos". Facultad de Informática; 2009.
25. Rodríguez D. Manual de Usuario: Suite de Geometría Descriptiva. Universidad de Matanzas.
Facultad de Informática; 2009.
76
Bibliografía
1. Larman C. Applying UML and Patterns. An introduction to Object-Oriented Analisys and Design and
the Unified Process. Prentice Hall; 2003.
2. PENTON R. Beginning C# Game Programming. Thomson; 2005.
3. Bishop J. C# 3.0 Design Patterns. O’Reilly; 2008.
4. Booch G. Core J2EE Paterns. Best Practices and Design Strategies. Sun Microsystems;
5. Canton MP. DirectX 3D Graphics Programming Bible. IDG Books Worldwide, Inc.; 2000.
6. Harrison LT. Introduction to 3D Game Engine Design Using DirectX 9 and C#. Apress;
7. Luna F. Introduction to 3D Game: Programming with DirectX 9.0. Wordware Publishing;
8. Hruby P. Model-Driven Design Using Business Patterns. Springer; 2006.
9. Cantor M. Object-Oriented Project Management with UML. John Wiley & Sons; 1998.
10. Mariñán MP. Patrones de diseño. Journal. 2003 Date.
11. Peckham J. Practicing Software Engineering in the 21st Century. IRM Press; 2003.
12. Donaldson SE. Successful Software Development. 2nd Edition. Prentice Hall; 2000.
13. Spolsky J. User Interface Design for Programmers. Apress; 2001.
14. Dykes L. XML For Dummies. Wiley Publishing; 2005.
77
Anexos
Anexo 1: Procecad
78
Anexo 2: Descriptive Geometry 1.32
79
Anexo 3: Proyección del punto A mediante un rayo proyectante que pasa por el polo S.
Anexo 4: Ejemplo de proyección ortogonal
80
Anexo 5: Proyección axonométrica del punto A
Anexo 6: Abatimiento en el sistema de dos planos
Anexo 7: Abatimiento en el sistema de tres planos
81
Anexo 8: Representación en el abatimiento de dos rectas paralelas
Anexo 9: Representación en el abatimiento de una recta paralela a un plano
82
Anexo 10: Representación en el abatimiento de dos rectas que se cortan
Anexo 11: Representación en el abatimiento de una recta que intercepta a un plano
83
Anexo 12: Herramienta StarUML
84
Anexo 13: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de representación de
un punto.
85
Anexo 14: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de representación de
una recta
86
Anexo 15: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de representación de
un plano.
87
Anexo 16: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de pertenencia de un
punto a una recta.
88
Anexo 17: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de pertenencia de
una recta.a una plano.
89
Anexo 18: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de pertenencia de un
punto a un plano.
90
Anexo 19: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de paralelismo entre
dos rectas.
91
Anexo 20: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de paralelismo entre
una recta y un plano.
92
Anexo 21: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de intersección entre
dos rectas.
93
Anexo 22: Herramienta Suite de Geometría Descriptiva. Ventana de ejercicios de intersección entre
una recta y un plano.
