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 a utomá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.
- Plantilla – Proyecto-preliminar
- Plantilla – Proyecto-final
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 clase ‘Main.java’ será utilizada para ejecutar su aplicación y evaluarla.
- 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.
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_pre_dd_mm_yy_HH_MM_SS (reemplazan por su fecha y hora de subida)* (Preliminar)
*entrega_final_dd_mm_yy_HH_MM_SS (reemplazan por su fecha y hora de subida)* (Final)
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).