Diseño
y Programación Orientados a Objetos
1er. Sem 2016
Tarea 2: Simulación Gráfica de Bolas Libres y Enlazadas en Espacio Cerrado como Objetos de
Software
Recomendación: Lea detenidamente la tarea. Si algo no lo
entiende, consulte en clases. Si es preciso, se incorporarán
aclaraciones al final.
Esta tarea tiene por objetivos:
* Crear de Interfaces gráficas en Java
* Manejar eventos de software.
* Ejercitar la creación y extensión de clases dadas para satisfacer nuevos requerimientos.
* Modelar un objeto físico como un objeto de software.
* Ejercitar una estrategia para programar simulaciones de fenómenos continuos.
* Conocer el patrón de diseño "Modelo-Vista-Controlador"
* Generar documentación con Javadoc
Descripción General
Como en la tarea 1,
en esta tarea se visualiza gráficamente la interacción de bolas,
resortes y contenedores en un espacio de dos dimensiones. No hay sin
roce ni gravedad. Además se incorporará un menú que permitirá agregar
nuevos elementos a la simulación y su edición. Otro menú permitirá
cambiar parámetros de la simulación como la distretización del tiempo y
el tiempo de refresco. Finalmente será posible guardar de forma
persistente (en archivo) la configuración actual para ser cargada a
futuro.
Como en la tarea 1, su grupo deberá desarrollar etapas o ciclos en un
proceso de desarrollo iterativo e incremental. En esta metodología cada
ciclo (etapa) genera una versión ejecutable que cubre un subconjunto de
los requerimientos finales deseados. Su programa podría ser mostrado a
un cliente y éste le podría hacer comentarios. La idea de esta
metodología, entre otras cosas, es involucrar al cliente para llegar a
un producto que lo deje satisfecho.
Etapa 1: En esta etapa usted debe analizar el siguiente código de
partida, el cual es una solución a la tarea1 extendida para su uso en esta tarea. Usted también puede ver el Diagrama de Clases para el código entregado.
Se eliminó la clase Vector2D para facilitar su lectura. Luego debe
corregir sus problemas de compilación para lograr generar una
ejeccución como la Figura 1.
Figura 1: Escenario resultante de la primera etapa
Etapa 2: En esta etapa usted
incorporará dos menús a la barra de menú según se muestra en figuras
Figura 2a y Figura 2b. Con Opción Edit usted podrá insertar Bolas y
receptáculos fijos (sólo el primero tiene sentido). La sección de un
resortee sólo posiciona uno de ellos en el área de trabajo pero nada
más ocurre con él. Esta opción sólo le permite ver la vista dde un
resorte pero no reflejar su dinámica. Las opciones bajo MyWorld
permiten iniciar y detener la simulación. Además la opción simulador
permite cambiar los parámetros de éste.
Figura 2a: Vista de las opciones del Menú Edit en paso
2.
Figura 2b: Vista
de las opciones del Menú MyWorld en paso 2.
Considere el código de apoyo a esta etapa para incluir estos menús.
Etapa 3: Posibilidad de
seleccionar y mover elementos físicos. Mientras la simulación esté
detenida, al seleccionar un elemento físico con el mouse presionando el
botón izquierdo sobre él, éste cambiará a color ROJO. Manteniendo el
mouse presionado el usuario podrá desplazar el mouse y con ello se
modificará la posición del elemento físico seleccionado. En el caso de
una bola, sus centro será arrastrado con el mouse. Para los resortes,
considere dos zonas circulares de selección ubicadas en cada uno de sus
extremos. Al presionar el cursos en una de ellas, el resorte
queda seleccionado y el usuario podrá arrastrar ese extremo del resorte
al arrrastrar el mouse. Si el resorte estaba ligado a una bola, su
desplazamiento lo libera de esa bola. Si la posición final al liberar
el mouse se ubica sobre una bola, se entenderá que el resorte debe
ligarse al centro de esa bola. Para el caso de un receptáculo,
considere dos zonas circulares seleccionables ubicadas en dos extremos
opuestos. Al presionar el cursos en una de ellas, el receptáculo queda
seleccionado y el usuario podrá modificar dos lados del recpetáculo al
arrastrar el mouse.
Para esta etapa usted puede considerar los cambios sugeridos para
MyWorldView, PhysicsElement y la clase MouseListener disponibles aquí. Haga todos los cambios que estime para cumplir lo pedido con la descripción de la tarea.
Etapa 4: Posibilidad de guardar
la configuración en archivo. Incorpore el menú File al lado izquierdo
del menú Edit. Bajo el menú File, presente dos opciones: Save y
Load. Con la opción Save y estando la simulación detenida, usted
podrá especificar el nombre de un archivo donde la aplicación
guardará el estado necesario para reiniciar la simulación en un
momento posterior. Ante la opción Load y estando la simulación
detenida, usted podrá cargar desde archivo una nueva configuracióon a
simular. Use la clase JFileChooser.
Trabajo a desarrollar
No
obstante se sugiere desarrollar cada etapa en el orden indicado, su
grupo puede entregar el código de la última etapa exitosamente
desarrollada y en otro los avances de la etapa siguiente si no alcanzó
a terminar.
Recuerde que cuenta con la ayuda del profesor y ayudante para
desarrollar
todas las etapas.
Resultados Esperados de su Grupo
Usted deberá documentar, usando notación "JavaDoc" las clases Ball y BallView de su última etapa.
Prepara un archivo makefile
para compilar y ejecutar su tarea en aragorn. Además incluya rótulos
"clean" para borrar todos los .class generados, y "doc" para generar la
documentación en directorio "documentation".
Entregue todo lo indicado en Normas de Entrega de Tareas. Su documentación automática con javadoc debe ser generable con:
$ make doc
(OJO no incluya las páginas html generadas por javadoc, éstas serán generadas por este comando cuando el ayudante las revise)
En su archivo de documentación (pdf o html) incorpore el diagrama de clases de la aplicación. Éste lo puede generar con jgrasp u otro programa.
Créditos extras: usted puede
aspirar a un puntaje adicional de 10 puntos creando un applet que
muestre la última etapa por usted desarrollada y excluyendo uso de menú File. El applet debe incluir
un frame interno (InternalFrame). Ojo esto es
opcional, usted debe rendir bien en los otros ramos también.
Ayudas
Dé una mirada a la solución parcial al problema. Si encuentra errores o algo que pueda ser mejorado, indíquelo claramente.
No dude en consultar al profesor o ayudante sobre dudas de esta tarea.
Sobre la arquitectura Modelo Vista Controlador
Para organizar interfaces gráficas una solución de software general recomendada (éstas son conocidas como patrones
de diseño) es la "modelo-vista-controlador".
El modelo la clase que caracteriza a un objeto y
almacena los datos significativos de éste. En este caso la clase
MyWorld maneja el modelo, también las clases Ball, Spring, Receptacle para
esas categorias de objetos. Por otro lado tenemos las vistas, estas clases
indican cómo esos datos se muestran visualmente. Estas clases representan
visualmente los objetos del problema. En nuestro caso MyWorld, Ball, Spring
y Receptacle poseen sus vistas en las clases MyWorldView, BallView,
SpringView, y ReceptacleView. No es el caso de esta tarea, pero por ejemplo
un objeto termómetro tendría un modelo y podría tener varias formas de mostrarse: como columna
de mercurio, como número digital, como un color, etc. Finalmente tenemos el
controlador. Las clases controladoras son aquellas que modifican los datos,
por ejemplo a través de las acciones del usuario en la interfaz.
Generalmente las clases controladoras son los "listeners" o manejadores de
los eventos que usted estima de interés. En esta tarea, la clase MyWorld
actúa también como controlador (pues implementa el listener del paso del
tiempo que luego modifica su estado). Otras clases controladoras son el
listener que responde a las opciones de selección del menú y el listener que
responde a los eventos del mouse, el cual cambia de posición los objetos
contenidos en la interfaz gráfica. Puede leer más sobre Model-View-Controller.
Sobre ejes coordenados y gravedad
En esta tarea estamos usando coordenadas que facilitan el despliegue de los
objetos y la interpretación de los eventos del mouse. Ciertamente no es
conveniente que un pixel corresponda a un metro. Si bien la programación se
simplificaría así, en esta tarea se ha incluido el mecanismo para
transformar coordenadas del mundo físico a los pixeles de una ventana
gráfica. Cabe mencionar que la coordenada (0,0) de los JPanels está en el
extremos superior izquierdo y no en el inferior izquierdo como podría ser en
ejes coordenados más habituales en geometría y física. Para colmo el
eje "y" crece hacia abajo, cuando lo habitual es que crezca hacia arriba.
Para corregir los ejes y cambiar la escala desde distancias en metros a pixeles, se ha usado la clase AffineTransform (transformada
afín). Como hay más ramos en los que usted debe rendir bien, estas
transformaciones están incluidas en el código base para esta tarea. Si desea
saber más o entender mejor este tema, ya sabe por dónde buscar, además de consultar al profesor.