Diseño y Programación Orientados a Objetos
1er. Sem 2015
Tarea 2: Simulación Gráfica de Bolas, Resortes, Osciladores y Amortiguadores 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:
* Ejercitar la creación 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 modela la interacción de resortes, bolas, osciladores y amortiguadores; pero esta vez se hace en forma gráfica. Como en la tarea 1, esta vez su grupo deberá desarrollar cuatro etapas o ciclos en un proceso de desarrollo iterativo e incremental. En esta metodología cada ciclo (etapa) debe generar una versión ejecutable de la solución.

Etapa 1:  En esta etapa su grupo es libre de usar el siguiente código de partida y completar lo necesario hasta que su aplicación muestre la simulación como la Figura 1.


Figura 1: Bola con movilimento rectilíneo en el plano.

Etapa 2
: Ésta incorpora resortes a la Etapa 1. Adicionalmente a lo hecho en Etapa 1, usted puede usar el siguiente código para trabajar lo faltante y generar el escenario como el de la Figura 2.


Figura 2: Sistema de dos bolas y un resorte.

Etapa 3: En este ciclo de desarrollo se incorpora clases para incorporar osciladores (Oscillator) y aportiguadorlases (Dashpot). Desarrolle la clase Oscillator de forma análoga a la clase Ball y la clase Dashpot de forma an+aloga a la clase Spring. 

Figura 3: Sistema Oscilador, resorte, bola y amortiguador

Etapa 4: Teniendo todos los elementos gráficos de la Etapa 3, usted debe incorporar un menú con sólo un ítem (Configuration) asociado a la única opción del menú (Insert). En ésta el programa parte con el escenario sin objetos y ante la selección de la opción Configuration de la opción Insert se debe generar un escenario similar al de la Figura 4. La idea es asemejar la configuración a una cuerda con un oscilador en uno de sus extremos. El otro extremo tiene un  amortiguado sujeto de un lado a un punto fijo. Usted decida el valor para los atributos de las masas, resortes y amortiguador. Use masas y resortes iguales.

Figura 4: Onda Estacionaria con pérdida de energía en un extremo


Trabajo a desarrollar
No obstante se sugiere desarrollar cada etapa en el orden indicado, su grupo puede entregar el código de cada etapa o poneer todas las clases en un directorio "comun" y en directorios separados poner la clase PhysicsLab.java correspondiente a cada etapa. Si no logra llegar a la última etapa, entregue el código hasta la etapa mayor alcanzada. Recuerde que cuenta la ayuda del profesor y ayudante para desarrollar todas las etapas.

Resultados Esperados de su Grupo
Usted deberá documentar, usando notación "JavaDoc" la clase Ball, BallView y MyWorld (No se pide todo para no hacer más de lo mismo).
En su archivo archivo makefile (nuevo link) (explicación nuevo link) para compilar y ejecutar su tarea en aragorn, 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
Para la ejecución de cada etapa incluya rótulos:
$ make e1    // por etapa 1, análogamente para las etapas 2,3, y 4.
(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 etapa 4 de la aplicación. Éste lo puede generar con jgrasp u otro programa. Además incluya una imágen de la ejecución de su programa para cada etapa.

Créditos extras
: Su grupo puede aspirar a un puntaje adicional de 10 puntos si agrega las clases elástico (Elastic) y su vista (ElasticView). Los elásticos se pueden modelar como resortes con constante de elasticidad no nula cuando está estirado más allá de su largo en reposo, y con constante de elasticidad nula si la distancia entre sus extremos es inferior a su largo en reposo. La representación gráfica de un elástico será la de una trazo recto (línea recta). Para demostrar el desarrollo extra, usted deberá incorporar -además de Configuration- la opción "Extra Credit" al menú Insert. La nota igualmente se satura en 100%.

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 ante cualquier dudas.

Sobre la arquitectura Modelo Vista Controlador
Para organizar interfaces gráficas una solución de software general y recomendada (éstas son conocidas como patrones de diseño) es la "modelo-vista-controlador". El modelo es el conjunto de clases que caracterizan a los objetos y almacenan los datos significativos del problema. En este caso la clase MyWorld maneja el modelo, también las clases Ball, Spring, FixedHook para esas categorias de objetos. Por otro lado tenemos las vistas, estas clases indican cómo esos datos se muestras visualmente. Estas clases representan visualmente los objetos del problema. En nuestro caso MyWorld, Ball, Spring y FixedHook poseen sus vistas en las clases MyWorldView, BallView, SpringView, y FixedHookView. No es el caso de esta tarea, pero por ejemplo un objeto termómetro 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.
Patrón de Diseño: MOdelo-vista-controlador

Fig. : Una forma de interacción típica de las componentes del patrón de diseño modelo-vista-controlador.

Sobre ejes coordenados
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.