# PRO - BAE - LND - ETS. Proyecto interdisciplinar 2022

Este proyecto se realizará de forma interdisciplinar abarcando contenidos de los módulos de ETS, PRO, LND y BAE

## ABP

Agrupamiento: 3-4 alumnos máximo.

## El producto o reto final

El objetivo final es construir una aplicación web que utilice herramientas, técnicas y destrezas adquiridas a lo largo del curso en los módulos que participan del proyecto.

Los alumnos elegirán un supuesto sobre una empresa real o ficticia. Se deberán redactar, en base a ese supuesto las necesidades del cliente en forma de historias de usuario. Se utilizará la aplicación **Trello** para gestionar el trabajo en equipo.

### BAE

A partir del supuesto seleccionado y del documento con los requisitos del cliente,se desarrollará el modelo Entidad/Relación, su diseño lógico y su diseño físico. El modelo debe estar normalizado en 3FN. Las operaciones mínimas a realizar serán las siguientes:

* Mínimo 4 tablas
* 5 consultas sencillas
* 5 Consultas con inner/right/left join
* 1 procedimiento/función almacenado.
* 1 trigger

### LND

* Se crearán las páginas que permiten interactuar con nuesta aplicación. Estas consistirán básicamente en formularios que permitirán recoger los datos de entrada y páginas que mostrarán el resultado de las operaciones.
* Las páginas deberán ser responsivas, como mínimo en tres diferentes tamaños de pantalla (móvil, tablet y PC)
* Las páginas deben cumplir el estandar W3C de accesibilidad .
* Recursos:
* [CSS Responsive](https://www.w3schools.com/css/css_rwd_intro.asp)
* [W3Schools](https://www.w3schools.com/html/html_accessibility.asp)
* [W3C Web Accessibility](https://www.w3.org/WAI/standards-guidelines/es#wcag2)
* [JavaScript en HTML]([https://www.w3schools.com/html/html_scripts.asp])
* [Accesibilidad Developer Mozilla](https://developer.mozilla.org/es/docs/Learn/Accessibility/HTML)

### PRO

* Se crearan o utilizaran clases para implementar la lógica de la aplicación
* Se utilizará el microframework de Python `bottle` para servir las páginas web y permitir el acceso desde el navegador a las mismas. Se explicará su uso en clase.
* Existen diferentes paradigmas a la hora de organizar el código de las aplicaciones. Para nuestra aplicación utilizaremos el paradigma **MVC** (Modelo Vista Controlador) veremos los fundamentos del mismo y cómo emplearlos en nuestro proyecto.
* Librería de Python `sqlite3` para acceder y realizar consultas a la base de datos de tipo `sqlite` que ofrece como ventaja la sencillez en el acceso a la misma debido a que se almacena en un fichero y no precisa de la utilización de un servidor para el acceso al gestor de base de datos.
* En una segunda fase del proyecto se utilizará el módulo `peewee` un ORM (Object Relational Mapping). Un ORM es una herramienta que nos permite mapear una base de datos con objetos de forma que no tenemos que realizar consultas SQL para interactuar con la misma, sino que mediante métodos de objetos podemos realizar todas las operaciones sobre la información almacenada en la base de datos.

### ETS

* Gestión agil del proyecto usando tableros en herramienta tipo board (Trello) en la que se realizará el seguimiento de las historias de usuario que describen las características del proyecto
* Git y Github. Todo el proyecto se almacenará en un repositorio de Github. Aprenderemos a utilizar la metodología de trabajo Github Flow para colaborar en el desarrollo del código. Para ello deberemos aprender nuevos conceptos y técnicas de Git como son el uso de **ramas** (branches), el fichero `.gitignore`, cómo deshacer modificaciones hechas en el código, ver el historial de modificaciones realizadas, etc.
* Uso de entornos virtuales de desarrollo para el proyecto. En su momento se vio en el módulo en uso de `venv` para empaquetar en la aplicación todos los ejecutables, las librerias y dependencias necesarias para tener todos los elementos para su funcionamiento empaquetadas en una carpeta. Uilizaremos dicha herramienta en nuestra aplicación.
* Refactorización de código.

## Evaluación
### ETS
* **Gestión del proyecto**:
* Se utiliza una herramienta de tipo tablero para gestionar las tareas y subtareas a implementar
* Se comparte el acceso al tablero con los profesores ([e-mail])
* En el tablero se incluyen tarjetas en las que se describe en forma de **historias de usuario** las actividades a realizar.
* En caso de ser necesario se detallan subtareas.
* Se realiza seguimiento en el tablero de las tareas que se están implementando y que se han completado.
* Se reescribe o reformula el contenido de las tarjetas para responder a los cambios que puedan producirse durante la vida del proyecto.
* **Uso de entornos virtuales**
* Se crea con el módulo de Python `venv` un entorno virtual en una carpeta que contendrá todas las dependencias de la aplicación.
* Se configura **VSCODE** para que use el interprete del entorno virtual
* Se crea fichero `requirements.txt` con las dependencias instaladas en el proyecto.
* **Repositorio en Github del proyecto**
* Uno de los miembros del grupo crea repositorio público en Github para alojar y realizar el seguimiento del avance del proyecto.
* Se incluye como colaboradores a todos los miembros del grupo y a los profesores (@ichigar)
* Se crea en la carpeta raíz del proyecto un fichero `.gitignore` para que no se sincronicen en el repositorio archivos y carpetas temporales; así como los archivos alojados en el entorno virtual.
* Se trabaja localmente usando `git` con una copia del proyecto alojada en el repositorio. Se sincronizan periódicamente (`git push` `git pull`) los cambios realizados.
* Se configura a todos los miembros como `CODEOWNERS` del repositorio.
* Se crea una rama para cada nueva funcionalidad que codifique cada miembro del grupo. El nombre de la rama expresa la funcionalidad en la que se trabaja.
* Se crean `pull request` y se realiza `merge` en la rama `main` de los cambios una vez que se revisa su correcto funcionamiento.
* Se realizan `commits` en cada cambio significativo (añadir ficheros, modificar ficheros, refactorización, ...) del código.
* Se usan textos descriptivos en los commits que expresan sin ambiguedad el cambio realizado.
* **Refactoriazación del código**
* Se establecen unas pautas comunes en el grupo a la hora de poner nombre a clases, métodos, funciones, variables y constantes en el programa.
* Todos los cambios de refactorización que se hagan al código se reflejan en commits. El texto descriptivo del commit debe incluir la palabra **refactoriza**
* Se realizan de forma manual o usando herramientas de **VSCODE** otros tipos de refactorizaciones:
* renombrar identificadores
* Extraer bloques de código que se repiten en funciones o métodos.
* Usar operador ternario en lugar de if-else
* Uso de listas por comprensión en lugar de bucles for.

#### Productos/entregas
* Tablero en Trello
* Código del programa en repositorio de GitHub
* commits de refactorización
* requirements.txt
* .gitignore
* Documento en formato markdown con algunos ejemplos de tipos de refactorización aplicados (segmentos de código antes y después de refactorizar.)
### PRO
* **Funcionalidad y legibilidad del programa**
* El programa final **funciona correctamente** y realiza todas las actividades especificadas en el proyecto.
* Los **nombres** de clases, métods, variables y constantes son significativos sin ambigüedad la información que almacenan o la funcionalidad que realizan.
* El código es **claro**, **eficiente** y **legible**
* **Clases para la lógica de negocio de la apliación**
* Se estructura mediante clases la lógica de negocio de la apliación.
* Las clases incluyen todas las operaciones necesarias para interactuar con la aplicación.
* Estas clases no incluyen níngún elemento de visualización de información.
* **Uso del microframewor bottle**
* Se definen las rutas las urls que implementarán cada una de las operaciones de la aplicación.
* La función asociada a cada ruta hace de controlador de la misma encargandose de obtener/almacenar datos y de mostrar las vistas necesarias en el navegador.
* Se separa el acceso a los datos de la visualización de formularios de entrada y salida con resultados de las consultas.
* Se usan plantilla para los elementos de la interfaz.
* **Uso de sqlite3 para acceso a la base de datos**
* Se instala el módulo en el entorno virtual del proyecto.
* Se convierte el sql con el diseño de tablas y consultas del supuesto realizado en **BAE** con `mysql` a `sqlite` mediante herramientas automatizadas de conversión.
* Se insertan en las tablas datos iniciales de ejemplo.
* Se utilizan utilidades de la librería para realizar las consultas.
* Se utiliza la herramienta gráfica `sqlite-browser` para comprobar que los cambios realizados desde la aplicación se ven reflejados en las tablas de la base de datos.
* El código final se guardará en una rama separada de nombre `sqlite`.
* **Uso del ORM peewee para el acceso a la base de datos**
* Se instala el módulo peewee en el proyecto.
* Se realiza una nueva rama `peewee` para implementar el acceso a datos usando el ORM. Se hara merge con la rama `main` al final del proyecto.
* Se crean las clases con la definción de los modelos de las tablas del proyecto.
* Se sustituyen los accesos a datos realizados con `sqlite3` por los métodos de las clases del `ORM`

#### Productos/entregas
* Código del proyecto en repositorio
* Clases de lógica de negocio
* Código del framework
* Rama `sqlite` con código usando módulo `sqlite3` para acceso a la base de datos.
* Rama `main` deberá contener el resultado final del proyecto usando el **ORM** `peewee` para operaciones con la base de datos.

### Común

* Presentación de exposición del proyecto

###### tags: `pro` `proyecto` `ets` `bae` `lnd`