Analisis Funcional SuperHero

Proyecto/Petición Nombre Proyecto/Petición 16/07/2021
IRSO
Análisis Funcional Materia: Integración de Sistemas
Alumno: Julio Alfredo Luque
Análisis Funcional
JlDevs
SUPERHERO
Autor Julio Alfredo Luque
Fecha de creación Fecha creación
Última actualización 16/07/2021 18:47:00
Versión 1.0
Aprobado Por Fecha
Julio Luque 15/07/2021
Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

1
Analisis Funcional SuperHero.docx
IRSO
Apartados
Apartados ............................................................................................................................................................. 2
1. Necesidad de Negocio. ..................................................................................................................................... 3
2. Objetivos de Negocio........................................................................................................................................ 3
3. Alcance. ............................................................................................................................................................ 4
4. Fuera del Alcance. ............................................................................................................................................ 6
5. Impacto. ............................................................................................................................................................ 6
a. Sistemas Afectados/Nuevos ......................................................................................................................... 7
b. Sistemas Aplicaciones-Módulos Afectados/Nuevos .................................................................................... 7
c. Actores Afectados/Nuevos ........................................................................................................................... 7
d. Procesos Afectados/Nuevos ......................................................................................................................... 8
e. Entidades Afectadas/Nuevas ........................................................................................................................ 8
6. Funcionalidad Situación Actual. ....................................................................................................................... 8
7. Funcionalidad Situación Futura. ....................................................................................................................... 8
8. Definición de la funcionalidad a implementar. ................................................................................................ 9
9. Descomposición de la Funcionalidad. ............................................................................................................10
10. Requerimientos Funcionales. .......................................................................................................................12
11.Diagrama casos de uso. .................................................................................................................................13
11.Diagrama Secuencia. .....................................................................................................................................15
12. Diagrama de Colaboracion. ..........................................................................................................................16
12. Diagrama de Actividad..................................................................................................................................17

2
IRSO
1. Necesidad de Negocio.
¿Por qué necesita el cliente este proyecto?
Todo cliente que quiera superarse y llevar su negocio a un nivel muy alto, necesita los servicios que
ofrecemos ya que le permitirá integrar sus servicios con y consumir los que ofrecemos sin necesidad de
hacer grandes cambios en sus sistemas.
Un paso posterior a la implementación de nuestros servicios es que a partir de ello, podrá crear un
sistema global que sea propio, y dependiendo la lógica de negocio que implemente, puede convertirse en
proveedor de sus propios servicios.
En resumidas cuentas, lo que hoy necesitan los clientes que quieren potenciar sus negocios es un
servicio de APIs del cual puedan consumir todo lo que necesitan y más, para ofrecer servicios a sus clientes.
Para este proyecto, la necesidad surgió cuando los clientes necesitaban implementar cambios en el
frontend sobre múltiples servicios ya que contaban con diversas tecnologías de frontend, (el cual
consideramos que merece una revisión) y como había que hacer muchos cambios sobre todos los servicios
de front, el cliente necesitaba un servicio de backend que resuelva todos esos incidentes asi reduciría el
tiempo que le llevaría implementar en todos servicios frontend y el costo que lleva el mismo.
El cliente necesitaba un solo servicio que resuelva todas las necesidades y el cual lleve la
responsabilidad de consulta, procesado, filtros, ordenación y por supuesto lógica de negocio, al cual, el
frontend solo deberá mostrar en las vistas esa información.
2. Objetivos de Negocio.
¿Qué objetivos quiere alcanzar el cliente con este proyecto?
Los objetivos que quiere alcanzar cada cliente al implementar este proyecto en el ciclo de vida de su
negocio, es cambiar el paradigma de como vienen operando de la manera tradicional a entrar en la carrera
digital de business intelligent y convertirse en simples actores del negocio en protagonistas.
Cuando un cliente quiere que su empresa se convierta en un gigante en su rubro, no solo necesita lo
que envuelve al negocio, sino necesita un sistema que lo respalde, el mismo debe ser confiable, seguro,
flexible, escalable y propio, y nuestro objetivo es brindarle al cliente esta herramienta.
El objetivo principal que tiene un cliente al contratar nuestros servicios, es ser pionero en su rubro,
para esto le ofrecemos digitalizar sus productos y pasar de ser un simple proveedor de bienes o servicios,
a brindar experiencias que cambiaran la vida de las personas.
Objetivos básicos que serán cubiertos:
• Aumentar ventas

3
IRSO
• Disminuir costes
• Aumentar satisfacción del cliente final
• Mejorar procesos internos
El objetivo del cliente fue implementar una solución compleja de la manera mas simple.
3. Alcance.
El alcance de este proyecto va desde lo que el cliente creía necesitar, hasta lo que el cliente realmente
necesita.
¿Qué vamos a construir para el cliente en el proyecto?
En este proyecto el cliente nos pidió incorporar una funcionalidad al conjunto de APIs que vienen
consumiendo para lo cual nos detallaron específicamente la necesidad que tenían, su problemática y el
impacto negativo que les genera no tenerlo, los daños colaterales del mismo, y los beneficios de contar
con la siguiente Api.
Para ello se nombro al proyecto SUPERHERO, pero al ser tan customizable, el cliente lo podrá
implementar en varios módulos de su aplicación con el nombre que mas le convenga.
NOTA: Entiéndase por “Superhéroe”, a todo recurso sobre el cual quieran impactar con este proyecto,
ya sea, personal, directivos, clientes, proveedores, etc.
Esta API, SUPERHERO, realizará lo especificado por el cliente y será un mantenimiento de superhéroes.
En primeras reuniones, el cliente nos detallo su necesidad, la cual fue descrita en los puntos anteriores,
y también nos indico en un listado lo que necesitaban, lo que creían que podía funcionar como solución a
su sistema, básicamente era la creación y mantenimiento de superhéroes.
Este mantenimiento debe permitir:
• Consultar todos los súper héroes.
• Consultar un único súper héroe por id.
• Consultar todos los súper héroes que contienen, en su nombre, el valor de un parámetro enviado
en la petición. Por ejemplo, si enviamos “man” devolverá “Spiderman”, “Superman”, “Manolito el
fuerte”, etc.
• Modificar un súper héroe.
• Eliminar un súper héroe.
• Que todos los servicios estén testeados.

4
IRSO
A partir de estas tarjetas iniciales, y después relevar las necesidades, y tras varias reuniones con el
cliente se definió que la solución para el cliente y lo que necesitaba era mucho mas grande ya que no solo
necesitaba un sistema de ABM en java, sino que necesitaban un sistema de ABM optimo con muchos
features que le den ventaja sobre el resto que van desde la lógica del negocio, hasta lo técnico, y los cuales
detallamos a continuación.
Puntos a tener en cuenta:
• Los súper héroes se deben guardar en una base de datos H2 en memoria.
• La prueba se debe presentar en un repositorio de Git. No hace falta que esté publicado. Se puede
pasar comprimido en un único archivo.
Puntos opcionales de mejora:
• Utilizar alguna librería que facilite el mantenimiento de los scripts DDL de base de datos.
• Implementar una anotación personalizada que sirva para medir cuánto tarda en ejecutarse una
petición. Se podría anotar alguno o todos los métodos de la API con esa anotación. Funcionaría de
forma similar al @Timed de Spring, pero imprimiendo la duración en un log.
• Gestión centralizada de excepciones.
• Test de integración.
• Presentar la aplicación dockerizada.
• Poder cachear peticiones.
• Documentación de la API.
• Seguridad del API.
Se valorará positivamente:
• El uso de TDD. En caso de subir la práctica a un repositorio, se pueden utilizar los commits para
ver el proceso.
• Aplicación de los principios SOLID.
Se construirá un microservicio en Java el cual contara con un API con endpoints qu sean escalables.

5
IRSO
4. Fuera del Alcance.
Para este proyecto, quedaran fuera de alcance las tecnologías que manejen concurrencia y seguridad.
La razón para dejar fuera de alcance estos issues, es la siguiente:
La concurrencia queda fuera de scope, porque en esta instancia y por pedido del cliente, será un
proyecto de backoffice, el cual estará administrado por personal interno del negocio, y la escalabilidad en
cuanto a las peticiones estará administrada por los devops, los cuales dockerizaran el proyecto, si bien el
mismo contara con un dockerfile garantizando la utilidad del mismo. El proyecto dockerizado permitirá
levantar instancias que absorberán la sobrecarga de peticiones con un balanceador de carga que
posteriormente se implementara con Ribbon.
La seguridad queda fuera des cope, porque la api vivirá dentro del ecosistema de los ambientes a
deployar, por lo cual, solo se desarrolla el servicio con la lógica y los componentes necesarios para que
funcione y puedan implementarlo en los ambientes, desarrollo, testing y producción. Si bien se entrega el
producto con un sistema de seguridad basado en auth0, el mismo ofrece las garantías básicas de un
software seguro, pero no tiene niveles de encriptación elevados porque eso lo manejara el cliente con un
sistema propio.
Algunos componentes que también quedan fuera de scope son aquellos que tiene que ver con la
infraestructura, aunque esta contemplado en el proyecto, pero este será un proyecto a implementar
dentro de una estructura existente.
5. Impacto.
El impacto que tendrá este proyecto, principalmente en los filtros de búsqueda que tiene el cliente
en su aplicación.
Otro impacto será en la limpieza del código del propio cliente en los intentos de implementación de
este servicio.
Un tercer impacto será en la velocidad de respuesta y visibilidad en la pagina al usuario final, ya que
el mismo tendrá tiempos mas cortos de renderización, por lo que lo perceptible al cliente final será, “es
muy rápido” lo cual deberá ser transparente al mismo, ya que no le significara una modificación en el flujo
de sus transacciones, sino que convertirá mas amena su estadía en la pagina y termine en una optimización
de los tiempos que maneje de forma personal.
El impacto mas importante que deseamos ofrecer, es que el cliente quede convencido y satisfecho de
que la API no solo resolvió su situación, sino que lo convirtió en protagonista de un cambio, y que el por
su cuenta se convirtió en un creador de soluciones.

6
IRSO
a. Sistemas Afectados/Nuevos
Los sistemas que se verán afectados son las vistas que ofrece al cliente, pero no se verán afectadas
las vistas que percibe el cliente, sino las vistas que ofrece el proveedor, en este caso la empresa que
nos contrató, ya que deberá modificar los servicios de Fronted, en principio, Angular y Rect, pero esto
puede aplicarse a todas las vistas que maneje el cliente, solo modificando los parámetros de consulta
pero bajo ningún punto de vista deberán modificar la lógica de negocio que fue absorbida desde el
front.
b. Sistemas Aplicaciones-Módulos Afectados/Nuevos
Los módulos que se verán afectados son los módulos de consulta y comunicación con el servicio,
en este caso con nuestra API, y deberán modificar las consultas asíncronas con Ajax.
Como modificación se tendrá que tener en cuenta que es un servicio restfull con las características del
mismo. Esto supone que al ser pedido el servicio de backend, el cliente cuente con un servicio de
frontend diseñado bajo los estándares de Restfull y de ser así, no debería suponer mas cambio que el
endpoint de consulta.
c. Actores Afectados/Nuevos
Los actores afectados serán aquellos que tengan la autorización para interactuar con el servicio
SUPERHERO bajo los permisos respectivos a su responsabilidad. Estos pueden ser Administradores,
Managers y Usuarios, ya que los mismos pertenecen a un sector especifico de la jerarquía de roles de
la aplicación propia del cliente.
Los actores afectados son los siguientes:
Administradores: Son los que tendrán permiso root. Estos permisos tiene alcance a todos los
servicios de la API SUPERHERO. Los permisos que cuentan los administradores están definidos
por el esquema de permisos del propio cliente
Managers: Los Managers son los que tienen permisos intermedios de acceso a la API
SUPERHERO. Estos son los actores que tendrán incidencia con el servicio de Backoffice. Los
permisos que cuentan los administradores están definidos por el esquema de permisos del
propio cliente
Usuarios: Los usuarios son los actores finales a los que “nuestro cliente” denomina “cliente” o
“usuario”. Los permisos que cuentan los administradores están definidos por el esquema de
permisos del propio cliente

7
IRSO
d. Procesos Afectados/Nuevos y Acutuales
Los procesos afectados en la implementación de este servicio son, principalmente los procesos
internos del provedos, ósea de JLDevs, ya que son los que tiene que crear, desarrollar y testear los
servicios en base a los requerimientos. Esto significa el inicio, el análisis, el desarrollo, el testeo UAT, y
la puesta en marca con un posterior soporte.
Los procesos afectados por parte de nuestro cliente es la hablitaciion de un endpoint de prueba para
la implementación de este servicio. Esto en caso de tener el servicio funcionando y en producción. En caso de
no tener desplegado en producción, el mismo puede ser implementado en las fases tempranas de desarrollo
del cliente ya que contamos con MockUps que pueden ser utilizados por el cliente en instancias tempranas
del desarrollo.
Un proceso afectado, es la puesta en marcha en productivo de los servicios, el cual es una suma de
ambos sistemas, frontend y backend. Esta puesta en marcha de ambos sistemas pueden ser incluidos en este
proyecto lo cual supone una delegación del usuario hacia nuestra parte para desarrollar un sistema de backend
para los servicios que el mismo necesite. Bajo este ultimo punto, ofrecemos una api con soporte FullStack en
caso de que el cliente quiera confiar en nosotros tamaña responsabilidad.
e. Entidades Afectadas/Nuevas
Un proceso afectado, es la puesta en marcha en productivo de los servicios, el cual es una suma de
ambos sistemas, frontend y backend. Esta puesta en marcha de ambos sistemas, pueden ser incluidos en este
proyecto pero estará sujeto a modificaciones posteriores pedidas por el cliente.
6. Funcionalidad Situación Actual.
La funcionalidad actual de los sistemas consumidos por el cliente, es la baja performance que ofrecen
y la limitada escalabilidad a la hora de implementar estos servicios similares a los que ofrecemos. Cuando
decimos similares, nos referimos a servicios que ofrecen las mismas soluciones pero no el mismo performace
en las mismas.
La baja performance de los servicios contratados hasta el momento y también los servicios
desarrollados por el propio cliente es parte de la necesidad por el que se contrato nuestros servicios porque
creemos, confiamos y sabemos que podemos ofrecerlos.
7. Funcionalidad Situación Futura.
La situación futura de los servicios que exportara el cliente serán optimas, y no subtejtivas ya que tiene
un coverage del 90% bajo testeos de alta concurrencia.

8
IRSO
Otra de las situaciones futuras que experimentara el cliente es un problema de que tiene pocos
recursos para administrarla. Esto es un buen problema ya que esto significara que necesita poner recursos
nuevos para atender a la gran afluencia de consultas sobre los servicios, nuevos clientes, nuevos usuarios,
nuevos datos, nuevos servicios futuros, etc., y asi experimentara un nivel de negocios nuevo y superior, lo
cual desde ya significara un aumento mayor de sus ingresos y una inversión mayor para nuevos proyectos.
8. Definición de la funcionalidad a implementar.
La implementación de la funcionalidad es el paso intermendo de pasar de la situación actual a la

situación futura y esto requiere en principio de un análisis en principio realizado en este docuemnto pero
también en documentos que serán reflejados en Jiras como incidencias o nuevos features que están
ubiados en el backlog del mismo.
Entre ellas esta el despliegue temprano de ambientes con respuestas definidas como echotests que
contienen respuesta mockeadas para simular acciones sobre las peticiones HTTP que garanticen un “caso
feliz” que puedan implementar en la vista.
Para esto usaremos las siguientes teconologias:
• Proyecto Maven
• Java 11
• Spring boot 2. Superior
• Maven 3.8.1
• Hibernate
• Jpa
• Postgre Sql
• Microservicios con Stack de Netflix
• Spring Reactor Webflux.

9
IRSO
9. Descomposición de la Funcionalidad.
La descomposición de las funcionalidades están claramente especificadas en la documentación hecha

por swagger o postman. Los mismos tienen funcionalidades que permiten a nuestros usuarios a consumir
nuestros servicios.
Sistema Tipo servicio Tipo consulta Identificador de consulta Id. parametros.
SUPER Consultas getBy Id Numero de Id

HERO
Name Nombre. Acepta porciones de
nombre que se utiliza en la
búsqueda por base de datos.
GetAll Sin parámetros
Alta Save Parámetros en el body Objeto Json a guardar
Modificación Update Parámetros en el body Objeto Json a actualizar
Baja DeleteBy Id Numero de id

10
IRSO
10.Requerimientos Funcionales
a. [Texto] Requerimiento Funcional #1: Consultar Superheroe

1. Especificación:
a. Introducción: Mediante este requerimiento se busca en el sistema un superhere de-
pendiendo los parámetros que requiera el cliente en su filtro. Los mismo pueden ser
por id o por nombre.
b. Entradas: nombre de Superheroe, o Id del mismo
c. Proceso:
o Validar si los inputs son validos
o Valida que el Superheroe exista en base de datos
o Analiza si el nombre del superhéroe hace match con el spell del repositorio.
o Mostrar el mensaje HTTP de respuesta OK
d. Salidas:
o HTTP 200 con el body del superhéroe consultado
b. [Texto] Requerimiento Funcional #1: Registrar Nuevo Superheroe

2. Especificación:
a. Introducción: Mediante este requerimiento se ingresa un nuevo usuario al sistema.
b. Entradas: nombre de Superheroe, Saga a la que pertenece el superheroe
c. Proceso:
o Validar si los inputs son validos
o Valida que el Superheroe no exista en base de datos
o Guardar en base de datos
o Actualizar el listado en cache
o Mostrar el mensaje HTTP de respuesta OK
d. Salidas:
o HTTP 200 con el body del usuario generado
o Numero de ID de supeheroe en la base de datos
c. Requerimiento Funcional #2: Modificar Superheroe

1. Especificación:
a. Introducción: Mediante este requerimiento se permite cambiar la información del
usuario registrado en el sistema.
b. Entradas: Id de superheroe
c. Proceso:
o Verificar que el Id de superheroe. exista.
o Buscar datos del superheroe en función al código ingresado.
o Mostrar los datos encontrados.

11
IRSO
o Modificar los datos la saga del superheroe.

o Guardar los datos con la información ingresada.
o Mostrar mensaje de confirmación.
d. Salidas: Respuesta http con el body del superhéroe modificado.
d. Requerimiento Funcional #3: Eliminar Superheroe

1. Especificación:
a. Introducción: Por medio de este requerimiento se permite eliminar un superheroe
del sistema.
b. Entradas: Id de superheroe.
c. Proceso:
o Verificar que el Id de superheroe exista.
o Buscar datos del juego en función al código ingresado.
o Mostrar los datos encontrados.
o Confirmar eliminación
o Actualizar el estado del superheroe a estado “inactivo”.
o Mostrar mensaje de confirmación.
d. Salidas:
o Superheroe eliminado.
o Estado actualizado.

12
IRSO
11. Diagrama Casos de Uso

13
IRSO

14
IRSO
12. Diagrama de Secuencias.

15
IRSO
13. Diagrama de Colaboracion.

16
IRSO
14. Diagrama de Actividad.

17

Analisis Funcional SuperHero

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis Funcional SuperHero

Cargado por

Copyright:

Formatos disponibles

Proyecto/Petición Nombre Proyecto/Petición 16/07/2021

Autor Julio Alfredo Luque

Fecha de creación Fecha creación

Última actualización 16/07/2021 18:47:00

Aprobado Por Fecha

Julio Luque 15/07/2021

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

¿Por qué necesita el cliente este proyecto?

¿Qué objetivos quiere alcanzar el cliente con este proyecto?

Objetivos básicos que serán cubiertos:

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

• Aumentar satisfacción del cliente final

• Mejorar procesos internos

¿Qué vamos a construir para el cliente en el proyecto?

Este mantenimiento debe permitir:

• Consultar todos los súper héroes.

• Consultar un único súper héroe por id.

• Modificar un súper héroe.

• Eliminar un súper héroe.

• Que todos los servicios estén testeados.

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

Puntos a tener en cuenta:

• Los súper héroes se deben guardar en una base de datos H2 en memoria.

Puntos opcionales de mejora:

• Gestión centralizada de excepciones.

• Presentar la aplicación dockerizada.

• Poder cachear peticiones.

• Seguridad del API.

• Aplicación de los principios SOLID.

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

4. Fuera del Alcance.

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

b. Sistemas Aplicaciones-Módulos Afectados/Nuevos

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

d. Procesos Afectados/Nuevos y Acutuales

6. Funcionalidad Situación Actual.

7. Funcionalidad Situación Futura.

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

8. Definición de la funcionalidad a implementar.

La implementación de la funcionalidad es el paso intermendo de pasar de la situación actual a la

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

La descomposición de las funcionalidades están claramente especificadas en la documentación hecha

Sistema Tipo servicio Tipo consulta Identificador de consulta Id. parametros.

SUPER Consultas getBy Id Numero de Id

GetAll Sin parámetros

Alta Save Parámetros en el body Objeto Json a guardar

Modificación Update Parámetros en el body Objeto Json a actualizar

Baja DeleteBy Id Numero de id

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

a. [Texto] Requerimiento Funcional #1: Consultar Superheroe

b. [Texto] Requerimiento Funcional #1: Registrar Nuevo Superheroe

c. Requerimiento Funcional #2: Modificar Superheroe

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

o Modificar los datos la saga del superheroe.

d. Requerimiento Funcional #3: Eliminar Superheroe

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

11. Diagrama Casos de Uso

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

12. Diagrama de Secuencias.

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición

13. Diagrama de Colaboracion.

Análisis Funcional Proyecto/Petición Nombre Proyecto/Petición