Diseño y Programación Orientados a Objetos
1er. Sem 2017
Tarea 1: Ascensor como Objeto de Software

Lea detenidamente la tarea. Si algo no lo entiende, consulte en clases. Si es preciso, se incorporarán aclaraciones al final.
Objetivos de la tarea:
* Ejercitar la configuración de un ambiente de trabajo para desarrollar aplicaciones en lenguaje Java (se sugiere trabajar con Jgrasp o Eclipse )
* Modelar objetos reales como objetos de software.
* Reconocer clases y relaciones entre ellas en códigos fuentes Java.
* Ejercitar la extensión de clases dadas para satisfacer nuevos requerimientos.
* Ejercitar la entrada y salida de datos.
* Conocer el formato .csv y su importación a una planilla electrónica.
* Ejercitar la preparación y entrega de resultados de software (creación de makefiles, readme, documentación, manejo de repositorio -GIT).
* Familiarización con una metodología de desarrollo "iterativa" e "incremental". 

Descripción General

  En esta tarea se pide modelar un ascensor de un edificio como un objeto de software. Los ascensores normalmente tienen: botonera en cada piso para solicitar ascensor, botonera dentro del ascensor (cabina) para indicar destino, la cabina misma con su motor, sensores de llegada de la cabina a cada piso, y una unidad de control con la lógica requerida para accionar la detención, subida y bajada de la cabina, además de apagar las luces de solicitud en botoneras, ver figura 1.



Figura 1: Modelo simplificado de un ascesor para cuatro pisos
Todos conocemos y hemos usado un ascensor alguna vez, por lo cual descripciones detalladas de todo no son necesarias. Cuando hay varios adyacentes, todos trabajan en conjunto. En esta tarea consideraremos un sólo ascensor. La solución a programar en esta tarea es simple; sin embargo, debe reflejar la operación de ascensores reales. Las botoneras poseen una luz integrada a cada botón.
(1) Así al "llamar" a un ascensor en una dirección (para subir o bajar desde un piso), se enciende el botón. Cuando el ascensor llega al piso en la dirección solicitada, se apaga el botón y se detendrá por al menos dos segundos.
(2) Al seleccionar un piso destino dentro de la cabina, se encenderá el botón asociado a ese piso. Cuando la cabina llega al piso, la luz de ese piso se apaga.
El modelo de la Figura 1 ayuda a identificar los elementos que constituyen el sistema y los correspondientes candidatos a objetos de software de una representación de todo esto vía software. 1 y 2 describen someramente dos casos de uso del sistema. Los requerimientos a cumplir por un sistemas de software se definen con textos de este tipo (lo veremos más adelante en el curso). De estas descripciones, los sustantivos son buenos candidatos para clases de objetos y las acciones (verbos) buenos candidatos a métodos.
La Unidad de Control es el "cerebro" del ascensor. Allí reside toda la lógica de su operación. Por ejemplo, ésta se entera cuando la cabina llega a un piso y apaga la luz de la botonera correspondiente. La tarea principal de la Unidad de Control es ordenar detener, subir o bajar a la cabina. En este modelo consideraremos al subsistema motor-cabina como un sólo objeto y le llamaremos cabina.
Su programa vinculará objetos de distintas clases de manera de simular el comportamiento del ascensor ante los eventos generados en las botoneras. Un archivo de texto será la entrada del programa y su formato el siguiente:

<tiempo>  <TAB>  <número de botonera>  <TAB>   <U | D | número de piso>  <RET>

Cada línea de este archivo de entrada representa un evento generado por alguna persona. <tiempo> es expresado en segundos y debe ser siempre ascendente. El <número de botonera> va de 0..número de pisos del edificio. El valor cero lo usaremos para señalar eventos de la botonera en la cabina. Otros números corresponderán a las botoneras de cada piso. U y D representan solicitud de subida (Up) o bajada (Down). Para el caso de botonera 0, el tercer campo será un número positivo. Si por alguna razón su archivo estuviera mal formado, el programa enviará el mensaje "Input file format error" y terminará.
Como salida, su programa enviará a pantalla una línea en los instantes en que cambie el estado de uno o más objetos (extensión .csv) con el siguiente formato:

<tiempo>   <TAB> <piso de la cabina> <estado sensores de piso> <TAB>  <estado luces de botonera de cabina> <TAB> <estado de luces de botones de subida de piso> <TAB> <estado de luces de botones de bajada de piso>  <RET>

Cada línea registra el estado del sistema cuando éste cambia. <tiempo> se expresa en segundos. El estado de sensores de piso se representa por una secuencia de 1 y 0 separados por espacios indicando el estado de los sensores desde el primer al último piso. El estado de las botoneras de cabina indica el estado de sus luces como 1 ó 0 para indicar encendida o apagada. De forma análoga se se muestra el estado de las luces de botones en cada piso. El primer y último piso son casos especiales, el estado de la luz de bajada en primer piso se mostrará como 0 (apagada). Lo mismo para la luz de subida del último piso. A través de una redirección de la salida a un archivo de texto con extensión .csv usted podrá generar un gráfico de los movimientos del ascensor en el tiempo. El formato .csv viene de "comma-separated values"; sin embargo, otros separadores son posibles. Planillas de cálculo como excel y otras pueden importar datos desde este formato.

Desarrollo en Etapas

Para llegar al resultado final de esta tarea usted aplicará la metodología "Iterativa e Incremental" para el desarrollo de software. Su grupo irá desarrollando etapas que irán abordando los requerimientos gradualmente. En cada etapa usted obtendrá una solución que funciona para un subconjunto de los requerimientos finales. Su grupo deberá entregar una solución para cada una de las etapas aún cuando la última integre las primeras. Esto tiene por finalidad, educar en la metodología iterativa e incremental.

Primera Etapa

Esta etapa sólo se implementa clases para representar la botonera de cada piso y la de cabina. El programa leerá los eventos del archivo de entrada y apagará el botón previamente encendido cuando uno nuevo sea presionado. Su grupo puede completar el código adjunto y verificar su salida. (Ver diagrama de clases del código sugerido, se extrajo clase ElevatorLab para claridad del diagrama)

Segunda Etapa

En esta segunda etapa se implementará la cabina (que incluye su motor) y los sensores de piso. Cada sensor se ubica en una posición específica de la caja del ascensor y la cabina circula por su interior. Por esta razón los sensores de piso y la cabina están en la caja del ascensor. Su grupo generará un programa de prueba stage2Test.java que hará subir la cabina desde el primer piso al último y luego bajar. La salida del programa debe mostrar los cambios de piso de la cabina y los cambios de estado de cada uno de los sensores de piso. Código ayudadiagrama de clases sugeridos para esta etapa.

Tercera Etapa

Como tercer paso su grupo debe incorporar la Unidad de Control. En esta etapa a la Unidad de Control llegan llegan las señales de la botonera de cada piso. Aquellas de la botonera de la cabina no son consideradas en esta etapa. En esta etapa la Unidad de Control recibe llamados desde cada piso y mueve la cabina a los pisos que corresponda. Una vez que llega al piso, apaga la luz del llamado y se detiene por 2 segundos. Su comportamiento equivale a un ascensor llamado desde distintos pisos sin que alguien ingrese a la cabina. Para evidenciar el funcionamiento de suprograma envía a la salida el estado el ascensor en formato indicado arriba de manera que se puede veridicar la opración del ascensor. Código ayuda y diagrama de clases sugeridos para esta etapa,

Cuarta Etapa

En esta etapa conecte la botonera de la cabina a la Unidad de Control. Modifique la lógica de la unidad de control para que ésta responsa según el comportamiento descrito para este ascensor básico.

Resultados Esperados de su Grupo

Si bien usted puede usar un IDE (Integrated Development Environment), usted debe saber cómo compilar y correr su tarea desde la línea de comandos.
Su tarea debe ser ejecutable en aragorn.elo.utfsm.cl usando:
  $ java ElevatorLab <nombre archivo de entrada> 
La salida del programa será a pantalla.
El programa corre hasta que procesa el último evento del archivo de entrada.

Usted deberá entregar los siguientes archivos:
- readme
- makefile     /* para compilar */
- Archivo de Documentación: para cada etapa, éste incluye el archivo de entrada usado por usted y la salida obtenida. En las etapas 2, 3 y 4 incluya un gráfico posición de la cabina versus tiempo. Indique las dificultades encontradas y cómo las resolvió.
- En directorios separados ponga los archivos de cada etapa.
Su programa no generará el gráfico, éste lo debe generar con una planilla de cálculo a partir de los datos de salida de su programa.

Extra créditos

   Su grupo puede aspirar a 5 puntos adicionales (la nota igualmente se satura en 100%) si agrega una luz para la cabina. Esta luz se enciende al llegar al piso del primer llamado y se apaga luego de 5 segundos sin recibir solicitudes después de haber satisfecho la última solicitud. Incluya  el estado de la luz en los eventos de salida. En archivo Readme indique si abordó este requerimiento.

Ayudas
* Revise las instrucciones parra la realización de tareas.
* Dé una mirada a los códigos de avance proporcionados. Si encuentra errores o algo mejorable, avise al profesor.
* Para enviar los datos a un archivo de salida, redireccione la salida a pantalla usando:
$ java ElevatorLab <nombre de archivo de entrada>  > miSalida.csv
  Luego trate este archivo como si fuera planilla electrónica. Usted podrá usar "tabs" y "espacios" como separadores de columnas.

* No dude en consultar al profesor o ayudantes sobre dudas de esta tarea.

Nociones de simulación de fenómenos continuos
.......