Sistemas de Información Empresarial Documentation

Sistemas de Información EmpresarialDocumentation

Release 0.1

Pablo Sánchez

Mar 25, 2021

Contenidos

1 Descripción del Sistema 3

2 Modelo de Dominio 9

3 Capa de Persistencia 11

4 Capa de Servicio 15

i

Sistemas de Información Empresarial Documentation, Release 0.1

Este documento contiene diversa información sobre el proyecto software que se deberá desarrollar para superar laasignatura de Tecnologías para el Desarrollo de Aplicaciones Empresariales sobre Internet, perteneciente al Másteren Ingeniería Informática de la Universidad de Cantabria.

Más concretamente, se incluye una descripción del sistema a desarrollar y, por cada etapa del proyecto, una brevedescripción de las tareas a realizar en dicha etapa, algunas indicaciones y consideraciones a tener en cuenta, loselementos a entregar y los criterios de evaluación.

Contenidos 1


2 Contenidos

CHAPTER 1

Descripción del Sistema

1.1 Polaflix: Un Sistema de Visualización de Series

Paco y Lola son dos oriundos de Polaciones que viven, por tanto, algo aislados del resto del mundo. A consecuenciade dicho aislamiento, Paco y Lola creen que el desarrollo de una plataforma web para la visualización de series detelevisión bajo demanda es una idea innovadora y un proyecto de éxito seguro.

La idea básica del sistema es que cada usuario con cuenta en el sistema pueda buscar una serie, añadirla a su espaciopersonal y visualizarla. Por cada capítulo visualizado, se cobrará al usuario una pequeña cantidad. Los cargos se vanacumulando en la cuenta del usuario y al final de cada mes se carga el recibo en la cuenta bancaria proporcionada porcada usuario.

Las series que ofrece el sistema se clasificarán inicialmente en tres categorías:

1. Estándar: series de menor demanda o actualidad (e.g., Los Serrano);

2. Silver: series de demanda o actualidad media (e.g., Paquita Salas);

3. Gold: para series de gran demanda y actualidad (e.g., Juego de Tronos).

La visualización de un capítulo de una serie estándar se cobrará inicialmente a 0.50C; el capítulo de una serie silvera 0.75C; y el de una serie gold a 1.50C. Para los grandes consumidores de series existe la opción de pagar una cuotafija mensual de 20C con la que poder visualizar todos los capítulos de todas las series que se desee.

Cada usuario, para poder acceder a la plataforma, tendrá que proporcionar un nombre de usuario, que será único paracada usuario dentro de la plataforma, una contraseña de acceso al sistema y una cuenta bancaria en formato IBAN.

Mientras cuidan de su nutrida y hermosa cabaña bovina, Paco y Lola han diseñado una serie de mock-ups que ilustrancómo debería funcionar su aplicación. El funcionamiento de Polaflix, de acuerdo con dichos mock-ups diseñados,sería tal como sigue.

Tras autenticarse en el sistema, cada usuario accede en primer lugar a su espacio personal (Figura 1). Dicho es-pacio personal deberá mostrar, para cada usuario, la lista de series que actualmente está viendo (etiquetadas comoEmpezadas), la lista de series que desea ver pero que aún no ha empezado (etiquetadas como Pendientes), y lalista de series que ha terminado de ver (etiquetadas como Terminadas).

3


Fig. 1: Figura 1. Página personal de inicio de un usuario Polaflix

4 Chapter 1. Descripción del Sistema


El nombre del usuario se muestra en la parte superior de la página. En el caso de la Figura 1, el usuario sería JohnNieve. Desde esta página, cada usuario puede realizar las siguientes acciones:

1. Seleccionar una serie para su visualización;

2. Navegar por el catálogo de series para agregar una nueva serie a la lista de pendientes;

3. Comprobar el estado de la factura actual o visualizar las facturas ya cobradas.

Cada una de estas acciones se describen a continuación.

1.2 Seleccionar una Serie para su Visualización

Si dentro de la página inicial (Figura 1) se selecciona una serie, de cualquier lista, la aplicación redirige a la interfazVer Serie (Figura 2). Esta página muestra, temporada por temporada, todos los capítulos que conforman hasta elmomento la serie seleccionada.

Fig. 2: Figura 2. Interfaz Ver Serie

Por cada capítulo se muestra el número de capítulo dentro de la temporada, su título, un enlace Ver que permite

1.2. Seleccionar una Serie para su Visualización 5


comenzar la visualización del capítulo, y, por último, una etiqueta que indica si el capítulo ha sido Visto o estáPendiente de visualización. Un capítulo se considera visto desde el mismo momento en el que comienza sureproducción. Es decir, el sistema no verifica que el capítulo haya sido visualizado de manera completa para marcarlocomo visto.

Cuando se abre la interfaz Ver Serie, si la serie a mostrar es una serie empezada, la interfaz se abre directamentepor la temporada correspondiente al último capítulo visualizado. En el caso de que la serie a visualizar esté pendienteo terminada, se abrirá siempre por la primera temporada. Además, si dentro de esta interfaz, se hace click o doble clicksobre el título de un capítulo, se deberá mostrar debajo de dicho título la descripción del correspondiente capítulo.

Por último, en la esquina superior derecha, junto al nombre de la serie, se deberá mostrar el tipo de serie de la que setrata: (1) estándar; (2) silver; o (2) gold.

1.3 Agregar una Nueva Serie

Al seleccionar la opción Agregar Serie (Figura 1), se debe redirigir el usuario a la interfaz de navegación por elcatálogo de la plataforma (Figura 3), la cual deberá mostrar el listado de todas las series disponibles.

Para facilitar la visualización de dicha lista, esta interfaz sólo mostrará, en una misma página, las series que comienzanpor una determinada inicial. Además, como era de esperar, la lista de series correspondientes a una misma inicial selistarán alfabéticamente ordenadas. Para facilitar la navegación por las diferentes letras del alfabeto, la interfaz deberádisponer en su parte superior de algún tipo de widget que permita cambiar la inicial que está siendo visualizada.

Junto a estos elementos se deberá incluir caja de búsqueda que permita buscar una serie directamente por su nombre.En este caso, si la búsqueda tiene éxito, la página deberá mostrar el listado de la inicial que corresponda con la serieencontrada destacada de algún modo dentro de dicho listado. Si una búsqueda concluyese sin éxito, la página mostrarásimplemente un cuadro de diálogo reportando el error.

Dentro del listado de series, al lado del nombre de cada serie se mostrará un enlace que permita agregar la serie a lapágina personal de cada usuario. Si la serie ya estuviese agregada, la acción no tiene efecto. Si la serie no estuviesepreviamente agregada, se incorporará a la lista de pendientes.

Por último, si dentro del listado de series, se selecciona el título de una serie, se deberá abrir bajo su título una pequeñasipnosis de la misma, junto con los nombres del creador o creadores de la series, así como una lista con sus principalesactores.

1.4 Comprobar Facturación

Cuando se selecciona la opción Ver Cargos (Figura 1), la aplicación redirigirá al usuario a la interfaz de control de lafacturación (Figura 4).

La interfaz de control de la facturación mostrará inicialmente la factura correspondiente al mes en curso. La facturade cada mes contendrá una entrada por cada capítulo visualizado en ese mes. Por cada entrada, se deberá mostrar:

1. La fecha de visualización del capítulo.

2. El nombre de la serie a la que pertenece el capítulo.

3. La temporada y número del capítulo visualizado.

4. El cargo correspondiente a dicho capítulo, en función de si pertenece a una serie estándar, silver o gold.

Por último, al final de cada factura se mostrará el importe total de la factura. En el caso de los clientes que opten porla opción de una cuota mensual fija, el importe total será siempre dicha cuota fija.

La interfaz deberá proporcionar además una serie de botones que permitan avanzar o retroceder el mes mostrado, demanera que sea posible la consulta y revisión de facturas correspondientes a meses anteriores al actual.



Fig. 3: Figura 3. Interfaz Ver Catálogo.

1.4. Comprobar Facturación 7


Fig. 4: Figura 4. Interfaz Ver Facturas.


CHAPTER 2

Modelo de Dominio

2.1 Descripción

El primer paso para la elaboración del proyecto consiste en la definición del modelo de dominio. Dicho modelode dominio deberá caracterizar el dominio de la aplicación. Para ello, el modelo de dominio deberá especificar loselementos que constituyen el problema que queremos resolver, los datos que contienen dichos elementos y las reglasde manipulación de dichos elementos. El modelo de dominio debe de estar libre de detalles de bajo nivel, propiosde tecnologías o formas de implementación concretas, constituyendo un lenguaje universal para el desarrollo de laaplicación que facilite la comunicación entre desarrolladores y stakeholders.

Con esta idea en mente, la filosofía de desarrollo Domain-Driven Design1 trata de establecer una serie de pautaspara una adecuada elaboración de un modelo de dominio. Para ello se distinguen entre diferentes tipos de entidadesde dominio, como Entities o Value Objects y se establecen una serie de reglas para establecer relaciones entre estoselementos. El seguimiento de estas reglas permite obtener modelos de dominio que preservan la integridad de suselementos mientras que se asegura una cierta facilidad de evolución.

2.2 Actividades a realizar

Para superar esta etapa del proyecto, el alumno deberá realizar las siguientes actividades.

1. Elaborar un modelo de dominio, representado mediante un diagrama de clases UML, que caracterice el* sistemaPolaflix* anterioremente descrito.

2. Clasificar los elementos del modelo anterior como Entities, Value Objects o Services.

3. Identificar los aggregates, destacando su aggregate root, del modelo creado.

4. Refactorizar el modelo de dominio inicialmente creado para que sea conforme a las reglas de Domain-DrivenDesign.

1

E. J. Evans. Domain-Driven Design. Addison-Wesley, 2003.

9


5. Implementar el modelo de dominio en Java, utilizando simplemente POJOs (Plain Old Java Objects), dentro deun proyecto Spring Boot.

2.3 Elementos a entregar

1. Uno o más diagramas de clase UML, representando el modelo de domino creadado y refactorizado.

2. Un documento de texto simple, o un archivo pdf no muy elaborado, donde se especifique de qué tipo (Entity,Value Object o Service) es cada elemento del modelo de dominio y qué aggregates existen dentro de dichomodelo, identificando por cada aggregate su aggregate root. Además, se deberán proporcionar todas las justifi-caciones que se consideren oportunas para justificar las decisiones anteriores.

3. El código resultante de transformar el modelo de dominio anterior a Java.

Para la elaboración del modelo de dominio se recomienda utilizar MagicDraw como herramienta de modelado, aunquese deja libertad al alumno para utilizar la herramienta de modelado que considere más adecuada, existiendo incluso laposibilidad de elaborar los modelos a mano. En este último caso, el alumno deberá cuidar la limpieza de los modeloscreados y escanearlos antes de su entrega.

2.4 Criterios de calificación

2.4.1 Modelo de Dominio

Para el modelo de dominio se valorará que:

• Sea correcto desde un punto de vista de sintáctico.

• Soporte todas las acciones a nivel de negocio que esté previsto realizar sobre dicho modelo de dominio.

• Sea conforme a las reglas de Domain-Driven Design.

• Facilite la gestión de las reglas de negocio asociadas al dominio.

• Facilite ciertas evoluciones fácilmente anticipables.

• Esté limpio, ordenado y sus nombres sean significativos.

2.4.2 Documento Domain-Driven Design

En este apartado se valorará simplemente que las entities, value objects y services, aggregates y aggregate rootsestén correctamente identificados, así como que las explicaciones proporcionadas sean coherentes y correctas desdeun punto de vista técnico.

2.4.3 Implementación de los POJOs

En este apartado se valorará que:

• La implementación creada sea conforme al modelo de dominio.

• La elección de las estructuras de datos para las colecciones sea adecuada.

• La lógica de negocio que se haya definido e implementado sea eficiente.

• Los diferentes elementos que conforman el modelo tengan correctamente definidos sus métodos equals yhashCode, y, opcionalmente, su método compareTo.

10 Chapter 2. Modelo de Dominio

https://www.nomagic.com/products/magicdraw

CHAPTER 3

Capa de Persistencia

3.1 Descripción

Un modelo de dominio, como el elaborado en la fase anterior del proyecto, permite representar y manipular una serieentidades conforme a las reglas de negocio de un determinado dominio o contexto de aplicación. Este modelo dedominio, y su implementación, nos permiten disponer de la lógica necesaria para pode gestionar los elementos dedominio de manera adecuada, atendiendo así las posibles peticiones de los usuarios del sistema.

No obstante, el modelo de dominio creado en el punto anterior adolece de un problema, que es que reside sólo enmemoria principal o RAM. Este hecho tiene asociado dos problemas fundamentales:

1. Si el número de elementos de dominio a gestionar es muy grande, nos quedaremos sin memoria rápidamente.

2. La memoria del sistema es volátil, por lo que cualquier corte en la alimentación del sistema hará que perdamoslos datos alojados en ella.

Por tanto, para que nuestra sistema sea útil desde un punto de vista práctica, necesitamos guardar los elementos denuestro modelo de dominio en algún tipo de almacén persistente, como una base de datos relacional o una hoja XML.



1. Anotar los POJOs creados como @Entity o @Embbedadable.

2. Proporcionar un identificador adecuadom, utilizando @Id para cada POJO. Decidir si dicho identificador seráautogenerado o no.

3. Anotar las propiedades de cada POJO, utilizando para ello @OneToOne, @OneToMany, @ManyToOne o@ManyToMany. Indicar, además para las asociaciones bidireccionales que lo necesiten, cual es la referenciaopuesta correspondiente.

4. Elegir una estrategia de propagación de operaciones cuando se considere necesario.

5. Anotar las jerarquías de herencia, justificando el patrón de transformación elegido en cada caso.

11


6. Crear los repositorios que se consideren necesarios para la gestión de la aplicación.

7. Utilizando los repositorios creados, cargar la base de datos con una serie de datos iniciales.

3.3 Ficheros Auxiliares

application.properties

CommandLineRunner


1. El código resultante de anotar con JPA los POJOs creados en la fase anterior.

2. Un documento de texto simple, o un archivo pdf no muy elaborado, que justifique las estrategias de herencia se-leccionadas, así como cualquier otro detalle que se considere relevante, como la elección de los idemtificadores.

3. El código resultante de añadir los repositorios que se consideren necesarios a la aplicación.


3.5.1 Anotaciones JPA

Para esta fase del proyecto se valorará que:

• La elección de @Entity o @Embbedadable sea coherente con respecto a lo definido en el documento deDomain-Driven Design.

• La elección de los identificadores es correcta y coherente.

• El uso de las anotaciones para transformaciones referencias y colecciones es correcto.

• En el caso de las asociaciones bidireccionales, los mappedBy están correctamente especificados.

• Las estrategias de propagación de operaciones son correctas y coherentes.

• La transformación de las jerarquías de herencia son correctas y coherentes.

3.5.2 Repositorios Spring JPA


• La definición de los repositorios sea correcta.

• Sólo existan repositorios para aquellos elementos de dominio que realmente lo precisen.

• El alumno sea capaz de cargar la aplicación con una serie de datos iniciales.

3.6 Trucos y Consejos

1. Se puede accedder a la consola de H2 a través de la URL http://localhost:8080/h2-console, salvoque se haya configurado para utilizar una URL diferente.

12 Chapter 3. Capa de Persistencia


2. Dentro de la consola de acceso a H2, para acceder al esquema creado, se debe proporcionar como JDBC URLla misma URL que se haya proporcionado para la propiedad spring.datasource.url dentro del ficheroapplication-properties.

3. Se recomienda crear un constructor vacío, aunque sea con visibilidad protegida, para cada entity.

3.6. Trucos y Consejos 13


14 Chapter 3. Capa de Persistencia

CHAPTER 4

Capa de Servicio

4.1 Descripción

Un modelo de dominio, como el elaborado en la fase anterior del proyecto, permite representar y manipular conformea las reglas de negocio de un determinado dominio una serie entidades pertenecientes a dicho dominio. Este modelode dominio, y su implementación, nos permiten disponer de la lógica necesaria para poder gestionar dicho dominio demanera adecuada, atendiendo así las posibles peticiones de los usuarios del sistema.

No obstante, el modelo de dominio creado no es capaz por sí mismo de atender a las peticiones de los potencialesclientes. Estas peticiones llegarán al sistema como paquetes HTTP, que es necesario descodificar y redirigir al métodoo a los métodos adecuados del modelo de dominio. A continuación, se deberán persistir todos los cambios realizadosen las entidades de dominio y componer una respuesta adecuada para el cliente que formuló la petición inicial, teniendoen cuenta los resultados obtenidos.

Para realizar todas las operaciones anteriores, es necesario la definición de una capa de servicio que contenga uncontrolador HTTP. En la mayoría de los sistemas hipermedia actuales, entre los que se encuentran los sistemas deinformación empresarial, este controlador HTTP se diseñan siguiendo las directrices de las arquitecturas REST.

Por tanto, en esta parte del proyecto crearemos una capa de servicio con controlador HTTP REST.



1. Identificar los recursos que formarán la API del sistema.

2. Proporcionar una URI adecuada para cada recurso.

3. Especificar qué verbos HTTP serán aplicables a cada recurso.

4. Por cada recurso y verbo, especificar la acción a realizar, posibles parámetros de entrada, respuestas propor-cionadas y uno o más modelos de respuesta.

5. Implementar los controladores REST utilizando las facilidades proporcionadas por Spring.

15


6. Definir e implementar las operaciones que estarán disponibles a nivel de servicio, utilizando las anotacionesproporcionadas por Spring para la gestión de transacciones.

7. Conectar los controladores HTTP con la capa de servicio.

4.3 Ficheros Auxiliares

Modelo Especificación de API Rest


1. Un documento de texto simple, o un archivo pdf no muy elaborado, que contenga la especificación de la APIREST creada.

2. El código correspondiente a la implementación de los controladores REST en Spring.

3. Los POJOs con anotaciones Jackson para especificar su serialización.

4. El código correspondiente a la implementación de la capa de servicio, con las anotaciones correspondientes parala gestión transaccional.


4.5.1 Especificación API REST


• Estén expuestos todos los recursos necesarios para el correcto desarrollo de la aplicación.

• No estén expuestos recursos que no se consideren necesarios para el desarrollo de la aplicación.

• La URI asociada a cada recurso es correcta.

• Se potencia el paso de parámetros por URI frente a los parámetros HTTP.

• Los verbos asociados a cada recurso permiten gestionarlos de manera adecuada.

• Cada verbo y recurso tienen parámetros de entrada cuando se considera necesario.

• Las respuestas para cada recurso y verbo cubren las diferentes posibles situaciones que puedan darsedurante la ejecución de una petición.

• Existen modelos de respuesta cuando sea necesario.

• Los modelos de respuesta ofrecen un balance adecuado entre la cantidad de información enviada yel número de peticiones que necesitan realizar los clientes para completar una determinada tarea.

4.5.2 Implementación Controladores REST


• Existe un controlador REST por cada aggregate root que sea necesario gestionar.

• Exista un método para cada par (recurso, verbo) contenido en la aplicación.

• Cada método esté correctamente asociado a su URI.

16 Chapter 4. Capa de Servicio


• Cada método recupera sus parámetros de manera adecuada.

• Cada método delega en la capa de servicio de manera correcta, cuando sea necesario.

• Cada método devuelve una respuesta adecuada en función del resultado de su ejecución.

4.5.3 Serialización JSON


• Se hayan utilizado anotaciones Jackson de manera adecuada para definir las propiedades que aparecerán en cadarespuesta HTTP y las que quedarán excluida.

• Se han utilizado de manera adecuada las anotaciones para cortar referencias circulares.

• Se han utilizado de manera adecuada las anotaciones para gestión de value objects.

• Se han utilizado definido y utilizado de manera adecuadas vistas que definan DTOs.

4.5. Criterios de calificación 17

Sistemas de Información Empresarial Documentation

Documents

Transcript of Sistemas de Información Empresarial Documentation