Universidad Peruana de Ciencias Aplicadas

Arquitectura de Aplicaciones Web

Práctica Calificada01
202302

Sedes: Todas
Duración:110 min
Profesores
Indicaciones:

 Las preguntas de tipo práctico serán entregadas a través de la opción examinar archivos.
 Debe subir el ejercicio con extensión .rar o .zip al Blackboard en la opción examinar de
donde descargó el examen. En el .rar deberá incluir también un archivo .doc con las
pantallas en Swagger o Postman que demuestren que la solución funciona.
 Recuerde que, de no asignar los nombres a todas las variables del programa, de acuerdo
con el formato solicitado afectará el puntaje especificado en la rúbrica.
 Puede utilizar ejercicios desarrollados en clase, como guía.
 No se permite copiar del compañero, se penalizará con nota cero para el desarrollo de
ejercicios iguales y evidencias de plagio.
 De no adjuntar su solución a través del aula virtual, la calificación será CERO.
Práctica:
Se solicita elabore una aplicación web y debe contar con las siguientes características:
a. Tecnologías

Spring Boot
Spring DataJPA
Base de Datos – PostgreSQL
b. Consideraciones:
 Utilizar una base de datos PostgreSQL
 Considere los campos mencionados en la tabla dada y la historia de usuario para el
modelo de la tabla en la base de datos.
 Implemente sólo lo solicitado en las historias de usuario.
 Los nombres de las variables del programa deben ser escritas en inglés
 Claridad y eficiencia de la lógica implementada,
 La organización de los componentes debe guardar coherencia con lo desarrollado en
clase.
 Los nombres de las variables de todo el programa deben contener las dos iniciales de
sus apellidos.

Variable: Edad
Apellido: Ramírez Méndez
Ejemplo: rmEdad

 El nombre de la base de datos:

La base de datos deberá estar implementada en PostgreSQL y deberá llamarse
apellidoPaternoBDPC2
 Las rutas de los controladores:
La ruta del controlador debe ser su apellido paterno.

 El nombre con el que debe crear el proyecto debe ser apellidoPaternoapellidoMaterno.

Enunciado

Se solicita desarrollar una API REST dedicada a gestionar información relacionada a los tickets para las
competencias de los partidos de futbol. La base de datos utilizada será PostgreSQL y se llamará
"apellidoPaternoBDPC2".

La API estará encargada de gestionar distintos aspectos de la competencia, y para ello se deben
implementar las siguientes historias de usuario:

1. HUB01: Como desarrollador, quiero registrar los tickets para una competencia para gestionarlos.
- Criterios de aceptación:
- Se debe permitir el registro de un ticket, considerando todos sus atributos obligatorios.
- El ticket debe recibir un ID único generado automáticamente.
- La fecha de emisión del ticket no debe ser proporcionada, la debe asignar el sistema.
- Se debe utilizar Swagger o Postman para visualizar la transacción.
- El registro insertado debe mostrarse en formato JSON.
- Se debe utilizar el patrón DTO (Data Transfer Object).

2. HUB02: Como desarrollador, quiero listar todos los tickets emitidos para gestionarlos.
- Criterios de aceptación:
- Se deben listar todas los ticketes emitidos, incluyendo todos sus atributos obligatorios.
- Se debe utilizar Swagger o Postman para visualizar la transacción.
- Los registros listados deben mostrarse en formato JSON.
- Se debe utilizar el patrón DTO.

3. HUB03: Como desarrollador, quiero buscar todos los campos tickets incluyendo la suma total del
importe pagado por fecha mayor o igual a la fecha de emisión de tickets para cumplir con el PB del
proyecto
- Criterios de aceptación:
- Se debe mostrar importe total percibido por los tickets que cumplen con el requisito.
- Se debe utilizar Swagger o Postman para visualizar la transacción.
- Los registros listados debe mostrarse debe mostrarse en formato JSON.
- Se debe utilizar el patrón DTO.

4. HUB04: Como desarrollador, quiero obtener la cantidad de tickets registradas por estadio para cumplir
con el PB del proyecto.
- Criterios de aceptación:
- Se debe mostrar la cantidad total de tickets emitidos.
- Se debe utilizar Swagger o Postman para visualizar el resultado de la transacción.
- La cantidad solicitada debe mostrarse en formato JSON.
- Se debe utilizar el patrón DTO.

Ticket
Id
Tribuna
cantidad
Precio
Fecha del partido
Fecha de emisión
Estadio
Rúbrica de Evaluación
Criterio de Excelente Promedio Deficiente
calificación
C01. Registrar Registra la funcionalidad solicitada en la Registra la funcionalidad No registra, tiene errores, no
historia de usuario A, y cumple con todos los solicitada en la historia de funciona.
criterios de aceptación. usuario, pero no cumple con
todos los criterios de aceptación
2 puntos 1 puntos 0 puntos
C02. Listar Lista la funcionalidad solicitada en la historia de Registra la funcionalidad No lista, no funciona.
usuario B, y cumple con todos los criterios de solicitada en la historia de
aceptación usuario, pero no cumple con
todos los criterios de aceptación
2 puntos 1 puntos 0 puntos
C03. Busca y Obtiene los registros y la suma total de montos No funciona, no se obtiene la
Obtiene suma solicitados para la fecha dada. Funciona. cantidad.
3 puntos 0 puntos
C04. Obtiene Obtiene la cantidad de entradas al estadio No funciona, no se obtiene la suma.
cantidad indicado. Funciona.
3 puntos 0 puntos
C05. Code El desarrollador organiza el código agrupando El desarrollador aplica sólo en No se evidencia un criterio de
Organization en paquetes y las clases según propósito o parte la organización del código, organización del código en paquetes
funcionalidad. Usa la estructura desarrollada en agrupando en paquetes y clases
clase. según propósito o funcionalidad
1 puntos 0.5 puntos 0 puntos
C06. Nombre Cumple con el nombre del proyecto y todas las Cumple parcialmente con el No aplica
de proyecto y variables del programa. nombre del proyecto y con las
variables en variables del programa
todo el
programa
2 puntos 1punto 0 puntos
C07.DTO Usa el patrón DTO No usa el patrón DTO
1 0
C08. Rutas Aplica el formato solicitado para las rutas de los No aplica el formato para las rutas
controladores. solicitadas.
1 puntos 0 puntos
C9.BD Cumple con el formato de nombre de BD No cumple con el formato de
solicitado. nombre solicitado.
1 puntos 0 puntos
C10.Código No hay líneas de código líneas que no cumplen Hay código que no hace nada
que no hace función alguna en la API.
nada
1 punto 0 puntos
 Universidad Peruana de Ciencias Aplicadas
Arquitectura de Aplicaciones Web
Práctica Calificada01
202302

Sedes: Todas
Duración:110 min
Profesores
Indicaciones:

 Las preguntas de tipo práctico serán entregadas a través de la opción examinar archivos.
 Debe subir el ejercicio con extensión .rar o .zip al Blackboard en la opción examinar de
donde descargó el examen. En el archivo .rar deberá incluir también un documento .doc
con las pantallas en Swagger o Postman que demuestren que la solución funciona.
 Recuerde que, de no asignar los nombres a todas las variables del programa, de acuerdo
con el formato solicitado afectará el puntaje especificado en la rúbrica.
 Puede utilizar ejercicios desarrollados en clase, como guía.
 No se permite copiar del compañero, se penalizará con nota cero para el desarrollo de
ejercicios iguales y evidencias de plagio.
 De no adjuntar su solución a través del aula virtual, la calificación será CERO.
Práctica:
Se solicita elabore una aplicación web y debe contar con las siguientes características:
c. Tecnologías

Spring Boot
Spring DataJPA
Base de Datos – PostgreSQL
d. Consideraciones:
 Utilizar una base de datos PostgreSQL
 Considere los campos mencionados en la tabla dada y la historia de usuario para el
modelo de la tabla en la base de datos.
 Implemente sólo lo solicitado en las historias de usuario.
 Los nombres de las variables del programa deben ser escritas en inglés
 Claridad y eficiencia de la lógica implementada,
 La organización de los componentes debe guardar coherencia con lo desarrollado en
clase.
 Los nombres de las variables de todo el programa deben contener las dos iniciales de
sus apellidos.

Variable: Edad
Apellido: Ramírez Méndez
Ejemplo: rmEdad

 El nombre de la base de datos:

La base de datos deberá estar implementada en PostgreSQL y deberá llamarse
apellidoPaternoBDPC2
 Las rutas de los controladores:
La ruta del controlador debe ser su apellido paterno.

 El nombre con el que debe crear el proyecto debe ser apellidoPaternoapellidoMaterno.

Enunciado

Se solicita desarrollar una API REST dedicada a gestionar información relacionada a mantenimiento de
maquinarias de una empresa. La base de datos utilizada será PostgreSQL y se llamará
"apellidoPaternoBDPC2".

La API estará encargada de gestionar distintos aspectos del mantenimiento, y para ello se deben
implementar las siguientes historias de usuario:

1. HUB01: Como desarrollador, quiero registrar las órdenes de mantenimiento de la maquinaria para
gestionarlas.
- Criterios de aceptación:
- Se debe permitir el registro de una orden, considerando todos sus atributos obligatorios.
- la Orden debe recibir un ID único generado automáticamente.
- La fecha de emisión de la orden no debe ser proporcionada, la debe asignar el sistema.
- El estado de ejecución inicial debe ser false.
- Se debe utilizar Swagger o Postman para visualizar la transacción.
- El registro insertado debe mostrarse en formato JSON.
- Se debe utilizar el patrón DTO (Data Transfer Object).

2. HUB02: Como desarrollador, quiero listar todos las ordenes emitidas para gestionarlas.
- Criterios de aceptación:
- Se deben listar todas las ordenes generadas, incluyendo todos sus atributos obligatorios.
- Se debe utilizar Swagger o Postman para visualizar la transacción.
- Los registros listados deben mostrarse en formato JSON.
- Se debe utilizar el patrón DTO.

3. HUB03: Como desarrollador, quiero buscar todos los campos de ordenes incluyendo, además, el
importe considerando el IGV (18%). La búsqueda debe ser por fecha mayor o igual que la fecha de
emisión de las órdenes para cumplir con el PB del proyecto
- Criterios de aceptación:
- Se debe mostrar todos los campos obligatorios y el importe incluido el IGV por las ordenes que
cumplen con el requisito.
- Se debe utilizar Swagger o Postman para visualizar la transacción.
- Los registros listados debe mostrarse debe mostrarse en formato JSON.
- Se debe utilizar el patrón DTO.

4. HUB04: Como desarrollador, quiero obtener la cantidad de ordenes registrados por Campamento para
cumplir con el PB del proyecto.
- Criterios de aceptación:
- Se debe mostrar la cantidad de órdenes emitidas.
- Se debe utilizar Swagger o Postman para visualizar el resultado de la transacción.
- La cantidad solicitada debe mostrarse en formato JSON.
- Se debe utilizar el patrón DTO.

Orden
Id
Descripcion
Importe
Fecha de emisión
Fecha programada
Estado de ejecución
Campamento
Rúbrica de Evaluación
Criterio de Excelente Promedio Deficiente
calificación
C01. Registrar Registra la funcionalidad solicitada en la Registra la funcionalidad No registra, tiene errores, no
historia de usuario A, y cumple con todos los solicitada en la historia de funciona.
criterios de aceptación. usuario, pero no cumple con
todos los criterios de aceptación
2 puntos 1 puntos 0 puntos
C02. Listar Lista la funcionalidad solicitada en la historia de Registra la funcionalidad No lista, no funciona.
usuario B, y cumple con todos los criterios de solicitada en la historia de
aceptación usuario, pero no cumple con
todos los criterios de aceptación
2 puntos 1 puntos 0 puntos
C03. Busca y Obtiene los registros y la suma total de montos No funciona, no se obtiene la
Obtiene suma solicitados para la fecha dada. Funciona. cantidad.
3 puntos 0 puntos
C04. Obtiene Obtiene la cantidad de entradas al estadio No funciona, no se obtiene la suma.
cantidad indicado. Funciona.
3 puntos 0 puntos
C05. Code El desarrollador organiza el código agrupando El desarrollador aplica sólo en No se evidencia un criterio de
Organization en paquetes y las clases según propósito o parte la organización del código, organización del código en paquetes
funcionalidad. Usa la estructura desarrollada en agrupando en paquetes y clases
clase. según propósito o funcionalidad
1 puntos 0.5 puntos 0 puntos
C06. Nombre Cumple con el nombre del proyecto y todas las Cumple parcialmente con el No aplica
de proyecto y variables del programa. nombre del proyecto y con las
variables en variables del programa
todo el
programa
2 puntos 1punto 0 puntos
C07.DTO Usa el patrón DTO No usa el patrón DTO
1 0
C08. Rutas Aplica el formato solicitado para las rutas de los No aplica el formato para las rutas
controladores. solicitadas.
1 puntos 0 puntos
C9.BD Cumple con el formato de nombre de BD No cumple con el formato de
solicitado. nombre solicitado.
1 puntos 0 puntos
C10.Código No hay líneas de código líneas que no cumplen Hay código que no hace nada
que no hace función alguna en la API.
nada
1 punto 0 puntos