|  |
ISIS1206 - Estructuras de Datos |
Envío de Proyectos
Estructura: Organización de su repositorio
Al igual que con los talleres es conveniente seguir una estructura canónica y fácil de navegación. A continuación es posible apreciar un ejemplo de la estructura que debería tener su repositorio para cumplir con la normatividad dispuesta para el envío de proyectos.
root
│ README.md
│ ...
│ Más archivos
│
├── src // Carpeta donde se almacena el código fuente
└── mundo // Paquete principal del mundo de su sistema (kernel)
├── Main.java // Clase principal que ejecuta la app
├── ... // Otros archivos java con el código fuente de la app
└── test // Paquete principal donde se deben almacenar todas las pruebas
│ ├── ... // Archivos java con el código fuente de las pruebas
└── api // Paquete donde se dejará las interfaces para ejecutar pruebas automáticas del curso
└── proyecto1
├── ... // Interfaces (contratos funcionales) para ejecución de pruebas automáticas por parte del monitor
└── proyecto2
├── ... // Interfaces (contratos funcionales) para ejecución de pruebas automáticas por parte del monitor
└── proyecto3
├── ... // Interfaces (contratos funcionales) para ejecución de pruebas automáticas por parte del monitor
├── docs
└── modeloClasesMundo.png // Modelo de clases del mundo de su sistema
└── proyecto1.pdf // Documento con la explicación del Proyecto 1 (ver plantilla)
└── proyecto2.pdf // Documento con la explicación del Proyecto 2 (ver plantilla)
└── proyecto3.pdf // Documento con la explicación del Proyecto 3 (ver plantilla)
├── data // Carpeta en donde se almacenan los datos de la app
├── dist // Carpeta en donde se almacena el archivo proyectoX.jar de la app
└── proyecto1.jar
└── proyecto2.jar
└── proyecto3.jar
├── docs // Carpeta en donde se almacena el javadoc de la app
├── lib // Carpeta con las librerías de la app
├── project.xml // Archivo con la configuración del proyecto en DrJava
├── build.xml // Archivo ant para compilar la app
├── run.sh // Archivo sh para ejecutar la app (Unix)
├── run.bat // Archivo bat para ejecutar la app (Windows)
A continuación se presenta un pequeño ejemplo de la estructura sugerida haciendo uso del Kernel:
Plantillas : Documentos para guíar la documentación
A continuación se presenta una plantilla para cada proyecto. Este es un documento .docx con la estructura a seguir en la entrega documental. Recuerde que para la entrega debe dejarlo en formato .pdf.
Condiciones esenciales para la evaluación
Es importante verificar las siguientes condiciones para que su taller pueda ser evaluado de forma correcta:
- La clase principal del proyecto deberá ser
Main.java. Usted puede crear otras clases y decidir su organización pero la claseMain.javaserá utilizada para ejecutar su aplicación y evaluarla. - El proyecto debe tener el archivo project.xml que permita abrirlo en DrJava.
- El proyecto cuenta con un paquete api el cual se divide en otros paquetes por cada proyecto. La idea es que usted debe seguir dichas interfaces e implementarlas de la forma que crea conveniente para que puedan ser validadas por medio de pruebas unitarias. Asuma que las interfaces son sólo una cara para que alguien externo tenga acceso a las capacidades de su software. Esto quiere decir que su mundo y arquitectura general pueden ser como usted crea conveniente pero su forma de comunicación con entes externos debe respetar completamente las interfaces propuestas para su proyecto.
Recomendaciones acerca del desarrollo del proyecto
Es posible desarrollar y editar los archivos que contienen el código fuente Java en diversos editores de texto diseñados específicamente para el desarrollo de código fuente en diversos lenguajes de programación, además de texto plano. Estos programas presentan diversas opciones de edición, tal como sintaxis resaltada, un intérprete en consola del lenguaje actual, así como atajos de teclado. Para el curso se utilizará DrJava un entorno liviano y versátil para el desarrollo de programas en Java, el cual está diseñado y ajustado específicamente a las necesidades presentadas en un entorno de aprendizaje. Otros editores que puede utilizar son gedit, Sublime Text, GNU Emacs o vi.
Sin importar la elección del entorno de desarrollo que sea pertinente y adecuada para cada estudiante, todo proyecto debe cumplir las normas presentadas en este documento.
1: Nota: DrJava actualmente solo soporta la especificación 7 del lenguaje Java.
Ayuda: Procesando un JSON
Para poder procesar correctamente un archivo en formato JSON puede utilizar la librería GSON la cual puede descargar del siguiente link. A continuación encontrará un ejemplo de como procesar un Stream de JSON usando GSON.
import java.io.IOException;
import java.io.StringReader;
import java.net.MalformedURLException;
import com.google.gson.stream.JsonReader;
import com.google.gson.stream.JsonToken;
public class ProcessJSON {
public static void main(String[] args) throws MalformedURLException, IOException
{
JsonReader reader = new JsonReader(new StringReader("[{\"atributo\":\"valor\", \"lista\":[{\"item\":\"item1\"}]}]"));
handleArray(reader); // En este caso porque sabemos que siempre nos va a llegar una lista de objetos
}
/**
* Cuando identifica que encontró un objeto se procesa los atributos atómicos y compuestos (como listas)
* @param reader
* @throws IOException
*/
private static void handleObject(JsonReader reader) throws IOException
{
reader.beginObject();
while (reader.hasNext()) {
JsonToken token = reader.peek();
if (token.equals(JsonToken.BEGIN_ARRAY))
handleArray(reader);
else if (token.equals(JsonToken.END_OBJECT)) {
reader.endObject();
return;
} else
handleNonArrayToken(reader, token);
}
}
/**
* Cuando detecta que hay un arreglo es llamado este método
* Los arreglos pueden contener objetos o elementos primitivos
*
* @param reader
* @throws IOException
*/
public static void handleArray(JsonReader reader) throws IOException
{
reader.beginArray();
while (true) {
JsonToken token = reader.peek();
if (token.equals(JsonToken.END_ARRAY)) {
reader.endArray();
break;
} else if (token.equals(JsonToken.BEGIN_OBJECT)) {
handleObject(reader);
} else if (token.equals(JsonToken.END_OBJECT)) {
reader.endObject();
} else
handleNonArrayToken(reader, token);
}
}
/**
* Cuando identificó que no son ni arreglos ni objetos sino tokens (primitivas) concretos
*
* @param reader
* @param token
* @throws IOException
*/
public static void handleNonArrayToken(JsonReader reader, JsonToken token) throws IOException
{
if (token.equals(JsonToken.NAME))
System.out.println(reader.nextName());
else if (token.equals(JsonToken.STRING))
System.out.println(reader.nextString());
else if (token.equals(JsonToken.NUMBER))
System.out.println(reader.nextDouble());
else if (token.equals(JsonToken.BOOLEAN))
System.out.println(reader.nextBoolean());
else
reader.skipValue();
}
}
Forma de entrega
Al igual que en los talleres, la entrega se debe hacer por medio de Bibucket. La única diferencia es que usted debe crear un branch de su master en Bitbucket con el siguiente formato:
entrega-dd-mm-yy-HH:MM:SS (reemplazan por su fecha y hora de subida)
Para crear un branch, en la interfaz web de Bitbucket al lado izquierdo seleccione lo opción branches y después crear un branch (hijo) sobre su master (padre).
FAQ: Preguntas comunes
Por una parte, afirma que debemos tener sólo una carpeta src con paquetes test y mundo, que aparentan ser para una sola aplicación. Ahora bien, en el paquete API hay carpetas para los 3 proyectos.
R: El kernel de tu sistema puede seguir siendo el mismo, puesto que el caso de estudio no cambia. Sin embargo, cada proyecto puede venir con diferentes requerimientos funcionales o incluso pueden ser los mismos pero con diferentes implementaciones. Piensa en algo como Facebook o incluso el mismo Bitbucket, ellos te podrían poner diferentes caras: una para móvil, otra para web, desktop, etc. Sin embargo el core sigue siendo el mismo. Esto con el motivo de que ustedes pueden estructurar su Kernel como deseen pero deben presentarnos por proyecto de cierta manera.
¿ A qué se refieren con interfaces? ¿Cómo deben estar relacionadas con el programa? Se supone que debemos hacer una API para lo que desarrollemos en src? A su vez, por qué hay carpetas para los 3 proyectos? ¿no se supone que en src sólo está el código de 1?
R: Son unas interfaces .Java. Básicamente lo único que deben hacer es implementar dichas interfaces como ustedes crean convenientes. Estas interfaces son contratos funcionales (que son básicamente los requerimientos del proyecto) de cómo ustedes nos deben entregar información para la ejecución de pruebas automáticas. De esta manera, nosotros sólo debemos ejecutar la clase que implementa la interfaz que les pasamos y verificar que dado un conjunto de entradas obtenemos el conjunto de respuesta esperado en un tiempo óptimo. Por tal motivo, implícitamente están desarrollando un API (no es propiamente algo web ni nada del estilo, es hacer implements de la interface que les pasemos).
Son 3 carpetas, dado que son 3 proyectos diferentes y cada uno va a tener diferentes interfaces. Sin embargo, por debajo sigues llamando al mismo Kernel (por ende es un solo src).
A su vez, la carpeta docs pide los documentos de explicación de cada proyecto, pero sólo pide 1 diagrama de clases. Esto quiere decir que vamos a construir los proyectos 2 y 3 extendiendo el 1?
R: Si, precisamente el modelo de clases puede cambiar en el transcurso del semestre pero se hace sobre un mismo sistema que evoluciona. Si ustedes lo desean, podrían hacer un modelo para cada entrega, sin embargo sería un copy-paste más un par de cosas nuevas.