Vous êtes sur la page 1sur 27

Framework unificado para desarrollo de interfaces J2EE

Documento de Arquitectura y Servicios


Versión 0.1

CASO DE PRUEBA:
Sistema para el alquiler, control de películas y
clientes en una videotienda

Documento de arquitectura
Y servicios
Versión <0.1>

Historia de Revisión
Fecha Versión Descripción Responsable
18/03/2005 <0.1> Creación. Cristian Castañeda.

INVESTIGADORES:

ALEJANDRO BAEZ
CRISTIAN CASTAÑEDA
DIEGO CASTAÑEDA

DIRECTOR:

JAVIER SANCHEZ
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

TABLA DE CONTENIDO
1. Introducción......................................................................................................... 4
2. Capa de base de datos ....................................................................................... 5
2.1 Plataforma ..................................................................................................... 5
2.2 Diseño (Diagrama entidad relación) .............................................................. 5
2.3 Implementación ............................................................................................. 7
2.3.1 Tabla constante....................................................................................... 7
2.3.2 Tabla pelicula ......................................................................................... 7
2.3.3 Tabla caja................................................................................................ 8
2.3.4 Tabla subtitulo ......................................................................................... 8
2.3.5 Tabla audio ............................................................................................. 8
2.3.6 Tabla contrato ......................................................................................... 9
2.3.7 Tabla persona ......................................................................................... 9
2.3.8 Tabla referencias..................................................................................... 9
2.3.9 Tabla factura ......................................................................................... 10
2.3.10 Tabla detalle........................................................................................ 10
3. Mapeo objeto - relacional .................................................................................. 11
3.1 Por que Hibernate?...................................................................................... 11
3.2 Modelo de objetos ....................................................................................... 11
4. Capa DAO ......................................................................................................... 14
4.1 Afiliados ....................................................................................................... 14
4.2 autorizados .................................................................................................. 15
4.3 Contratos ..................................................................................................... 15
4.5 Facturas....................................................................................................... 16
4.6 Películas ...................................................................................................... 17
4.7 Referencias.................................................................................................. 17
4.8 Roles............................................................................................................ 18
5. Capa de servicios.............................................................................................. 19
5.1 Contratos ..................................................................................................... 19
5.1.1 Crear contratos...................................................................................... 19
5.1.2 Eliminar contratos (desafiliar)................................................................ 19
5.1.3 consultar contratos ................................................................................ 20
5.1.4 Agregar Autorizado ............................................................................... 20
5.1.4 Eliminar Autorizado ............................................................................... 20
5.1.5 Actualización de afiliados ...................................................................... 21
5.1.6 Actualización de autorizados................................................................. 21
5.2 Películas ...................................................................................................... 21
5.2.1 Creación Películas: ............................................................................... 21
5.2.2 Consulta de Películas:........................................................................... 21
5.2.3 Actualización de Películas:.................................................................... 22
5.2.4 Eliminar Películas:................................................................................. 22
5.2.5 Alquilar películas ................................................................................... 22

2
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

5.2.6 Entrega películas................................................................................... 23


5.3 Facturas....................................................................................................... 23
5.3.1 Creación de Facturas: ........................................................................... 23
5.3.2 Consultar Facturas: ............................................................................... 23
5.3.3 Eliminar Facturas: ................................................................................. 24
5.4 Reportes ...................................................................................................... 24
5.4.1 Películas prestadas en un rango de fechas. ......................................... 24
5.4.2 Películas en mora a la fecha. ................................................................ 24
5.4.3 Facturas emitidas en un rango de fechas ............................................. 24
5.4.4 Clientes en mora ................................................................................... 25
6. Capa de interfaz ................................................................................................ 26
7. Conclusiones..................................................................................................... 27

3
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

1. Introducción
Para la verificación de los resultados del proyecto titulado: “Framework unificado
para desarrollo de interfaces J2EE con soporte a objetos persistentes en bases de
datos relaciónales”, se ha decidido el desarrollo de una aplicación que nos sirva
para probar los resultados de este.

Luego de analizar varias opciones, decidimos desarrollar una aplicación para una
videotienda, debido que al desarrollar esta aplicación se podrán verificar muchos
elementos que serán manejados dentro del desarrollo de este proyecto, tales
como manejo de interfaces y manejo de objetos persistentes entre otros.

En este documento se describe el diseño de la arquitectura para la aplicación.


Para este proyecto hemos definido una arquitectura multicapas, entre las capas
que hemos definido tenemos: Base de datos, mapeo objeto – relacional, DAO,
business services e interfaz.

Lo que presentaremos mas adelante es la explicación de por que de estas capas y


cual fue el diseño en las capas que sea conveniente.

4
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

2. Capa de base de datos

En el diseño de cualquier aplicación de software, una de las cosas que se debe


mirar con mayor cuidado es la manera en que se manejara la información que se
necesita que sea persistente. De este diseño depende en gran medida que el
desarrollo de la aplicación sea exitoso, ya que sobre este diseño se basara en
gran medida el diseño posterior de la aplicación.

Para nuestro caso de la videotienda, se ha diseñado un modelo para el manejo de


los datos pensando en que este debe ser lo suficientemente general, para que se
pueda realizar un buen modelamiento en la capa de mapeo objeto – relacional, lo
cual nos permitirá tener un mejor desempeño en el desarrollo del proyecto.

2.1 Plataforma

Para la implementación del diseño de la base de datos de nuestra aplicación de la


videotienda, será sobre ORACLE, ya que sobre esta plataforma existe la facilidad
de que podemos trabajar sobre el servidor de la universidad y esta lo
suficientemente probada como para que se avale su uso. Además, todos los
integrantes del grupo tenemos conocimiento de la plataforma.

2.2 Diseño (Diagrama entidad relación)

Basándonos en documentos anteriores como el de casos de uso (v1.0) y de


requerimientos (v 1.0) se realizo un diseño para la base de datos en el que se
tenía en cuenta la forma en que esta podía responder para satisfacer todas las
necesidades que se definieron.

A continuación se muestra el modelo que sirvió para la base de datos de la


aplicación de la videotienda:

5
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

Cada una de las entidades representa:

• Película: Entidad que representa una película que se tiene en la


videotienda, Las películas pueden ser alquiladas y sobre estas se pueden
cobrar multas.

6
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

• Subtitulo: Indica los idiomas en los que esta subtitulada una película.
• Audio: sirve para representar los distintos idiomas en que esta hablada una
película.
• Constante: Entidad donde se guardan los valores globales que maneja el
sistema.
• Caja: Entidad que sirve para representar las diferentes categorías que
pueden tener las películas según su importancia o antigüedad.
• Persona: Representa los distintos tipos de clientes que pueden interactuar
con la videotienda. Pueden ser afiliados o beneficiarios.
• Referencias: Sirve para guardar las referencias personales asociadas a un
contrato.
• Contrato: Sirve para representar una afiliación de una persona a la
videotienda.
• Factura: Sirve para representar los ingresos de la videotienda. Están
asociados a un contrato.
• Detalle factura: Sirve para representar los distintos rubros que pueden ser
cobrados en una factura.

2.3 Implementación

Para la implementación del modelo anteriormente descrito se crearon las


siguientes tablas en la base de datos:

2.3.1 Tabla constante

CREATE TABLE CONSTANTE(


ID NUMBER(5) NOT NULL,
PADRE NUMBER(5) NOT NULL,
NOMBRE VARCHAR2(20) NOT NULL,
CONSTRAINT CON_PK PRIMARY KEY(ID));

2.3.2 Tabla pelicula

CREATE TABLE PELICULA(


ID NUMBER(5) NOT NULL,
CODIGO NUMBER(20) NOT NULL,
NOMBRE VARCHAR2(20) NOT NULL,
DESCRIPCION VARCHAR2(20),
ACTOREs VARCHAR2(20),
ANO NUMBER(4) NOT NULL,
ALQUILADA NUMBER(1) NOT NULL,

7
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

DURACION NUMBER(3) NOT NULL,


ID_TIPO_FORMATO NUMBER(5) NOT NULL,
ID_TIPO_GENERO NUMBER(5) NOT NULL,
CONSTRAINT PEL_PK PRIMARY KEY(ID),
CONSTRAINT PEL_FOCON_FK FOREIGN KEY (ID_TIPO_FORMATO)
REFERENCES CONSTANTE(ID),
CONSTRAINT PEL_GECON_FK FOREIGN KEY (ID_TIPO_GENERO)
REFERENCES CONSTANTE(ID));

2.3.3 Tabla caja

CREATE TABLE CAJA(


ID_TIPO_CAJA NUMBER(5) NOT NULL,
VALOR NUMBER(15,3) NOT NULL,
DIAS NUMBER(3) NOT NULL,
MULTAS NUMBER(15,3) NOT NULL,
CONSTRAINT CAJ_PK PRIMARY KEY(ID_TIPO_CAJA),
CONSTRAINT CAJ_CACON_FK FOREIGN KEY (ID_TIPO_CAJA)
REFERENCES CONSTANTE(ID));

2.3.4 Tabla subtitulo

CREATE TABLE SUBTITULO(


ID_PELICULA NUMBER(5) NOT NULL,
ID_TIPO_SUBTITULO NUMBER(5) NOT NULL,
CONSTRAINT SUB_PK PRIMARY KEY(ID_PELICULA,ID_TIPO_SUBTITULO)
CONSTRAINT SUB_PEL_FK FOREIGN KEY (ID_PELICULA) REFERENCES
PELICULA(ID),
CONSTRAINT SUB_SUCON_FK FOREIGN KEY (ID_TIPO_SUBTITULO)
REFERENCES CONSTANTE(ID));

2.3.5 Tabla audio

CREATE TABLE AUDIO(


ID_PELICULA NUMBER(5) NOT NULL,
ID_TIPO_AUDIO NUMBER(5) NOT NULL,
CONSTRAINT AUD_PK PRIMARY KEY(ID_PELICULA,ID_TIPO_AUDIO),
CONSTRAINT AUD_PEL_FK FOREIGN KEY (ID_PELICULA) REFERENCES
PELICULA(ID),
CONSTRAINT AUD_AUCON_FK FOREIGN KEY (ID_TIPO_AUDIO)
REFERENCES CONSTANTE(ID));

8
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

2.3.6 Tabla contrato

CREATE TABLE CONTRATO(


ID NUMBER(5) NOT NULL,
NUMERO NUMBER(20) NOT NULL,
FECHA DATE NOT NULL,
ID_PERSONA NUMBER(5) NOT NULL,
CONSTRAINT CONT_PK PRIMARY KEY(ID));
CONSTRAINT CONT_PER_FK FOREIGN KEY (ID_PERSONA) REFERENCES
PERSONA(ID));

2.3.7 Tabla persona

CREATE TABLE PERSONA(


ID NUMBER(5) NOT NULL,
CEDULA NUMBER(20) NOT NULL,
NOMBRE1 VARCHAR2(20) NOT NULL,
NOMBRE2 VARCHAR2(20) NOT NULL,
APELLIDO1 VARCHAR2(20) NOT NULL,
APELLIDO2 VARCHAR2(20) NOT NULL,
DIRECCION VARCHAR2(20) NOT NULL,
TELEFONO NUMBER(20) NOT NULL,
NOMBRE_EMPRESA VARCHAR2(20),
DIRECCION_EMPRESA VARCHAR2(20),
TELEFONO_EMPRESA NUMBER(20),
EMAIL VARCHAR2(20),
ID_CONTRATO NUMBER(5) NOT NULL,
ID_TIPO_PARENTESCO NUMBER(5) NOT NULL,
ID_TIPO_PERSONA NUMBER(5) NOT NULL,
CONSTRAINT PER_PK PRIMARY KEY(ID),
CONSTRAINT PER_CONT_FK FOREIGN KEY (ID_CONTRATO) REFERENCES
CONTRATO(ID),
CONSTRAINT PER_PACON_FK FOREIGN KEY (ID_TIPO_PARENTESCO)
REFERENCES CONSTANTE(ID));

2.3.8 Tabla referencias

CREATE TABLE REFERENCIAS(


ID NUMBER(5) NOT NULL,
NOMBRE VARCHAR2(20) NOT NULL,
TELEFONO NUMBER(20) NOT NULL,

9
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

ID_CONTRATO NUMBER(5) NOT NULL,


CONSTRAINT REF_PK PRIMARY KEY(ID),
CONSTRAINT REF_CONT_FK FOREIGN KEY (ID_CONTRATO) REFERENCES
CONTRATO(ID));

2.3.9 Tabla factura

CREATE TABLE FACTURA(


ID NUMBER(5) NOT NULL,
FECHA DATE NOT NULL,
VALOR NUMBER(15,3) NOT NULL,
PAGADO NUMBER(1) NOT NULL,
ID_CONTRATO NUMBER(5) NOT NULL,
CONSTRAINT FAC_PK PRIMARY KEY(ID),
CONSTRAINT FAC_CONT_FK FOREIGN KEY (ID_CONTRATO) REFERENCES
CONTRATO(ID));

2.3.10 Tabla detalle

CREATE TABLE DETALLE(


ID NUMBER(5) NOT NULL,
VALOR NUMBER(15,3) NOT NULL,
FECHA_ENTREGA DATE NOT NULL,
ID_PELICULA NUMBER(5) NOT NULL,
ID_TIPO_DETALLE NUMBER(5) NOT NULL,
ID_FACTURA NUMBER(5) NOT NULL,
CONSTRAINT DET_PK PRIMARY KEY(ID),
CONSTRAINT DET_PEL_FK FOREIGN KEY (ID_PELICULA) REFERENCES
PELICULA(ID),
CONSTRAINT DET_DECON_FK FOREIGN KEY (ID_TIPO_DETALLE)
REFERENCES CONSTANTE(ID)
CONSTRAINT DET_FAC_FK FOREIGN KEY (ID_FACTURA) REFERENCES
FACTURA(ID));

• Así mismo, se crearon índices, constraints de unicidad y números de


secuencia para aseguras un mejor manejo de la base de datos.

10
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

3. Mapeo objeto - relacional


La siguiente capa en nuestra arquitectura es la capa de mapeo objeto – relacional.

Esta capa surge de la necesidad de tener un nivel de mayor abstracción del


manejo de los datos. Teniendo esta capa, se podrá encapsular al usuario del
diseño, implementación y uso directo de la base de datos, lo que hace que se
puedan simplificar muchas etapas del proceso de desarrollo.

Además al utilizar una herramienta que nos permita realizar mapeos de este tipo,
se podrá establecer una clara separación del paradigma relacional (bases de
datos) y el paradigma orientado a objetos (clases), lo cual nos permitirá tener un
mayor grado de definición para cada una de las capas de la arquitectura.

Para nuestra aplicación, hemos decidido utilizar el framework Hibernate.

3.1 Por que Hibernate?

A continuación se presentaran algunas de las razones por las que se escogió


Hibernate como framework para el mapeo objeto – relacional:

• Es open source
• Es un framework maduro, ya que es uno de los mas utilizados actualmente
con muy buenos resultados.
• Hibernate da un completo soporte al modelo de programación orientado a
objetos, lo cual es una ventaja en el desarrollo de este proyecto ya que este
se hará sobre JAVA.
• Ofrece un lenguaje natural para la búsquedas en la base de datos (HSQL)
que es muy similar al que hemos manejado(SQL).
• Maneja XML para los mapeos, lo que hace que estos sean de fácil
entendimiento por la estructura que este maneja.

3.2 Modelo de objetos

A continuación se muestra el modelo de objetos que nos servirá para representar


a la videotienda a partir del diagrama entidad relación, que fue descrito en el
numeral 2.2 de este documento. Todos estos objetos van a ser POJO´s (persistent
old java objects) dentro de nuestra aplicación y se encontraran dentro del paquete
Co.Edu.Javeriana.Fwj2ee.Persistent.

11
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

12
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

En el anterior diagrama cada uno de los objetos representa:

• Película: Objeto que representa una película que se tiene en la videotienda,


Las películas pueden ser alquiladas y sobre estas se pueden cobrar multas.
• Constante: Objeto donde se guardan los valores globales que maneja el
sistema. Estos valores pueden ser: subtítulos, genero, formatos o audio.
• Caja: Objeto que sirve para representar las diferentes categorías que
pueden tener las películas según su importancia o antigüedad.
• Persona: Representa los distintos tipos de clientes que pueden interactuar
con la videotienda.
• Referencia: Objeto que hereda de persona y que representa las referencias
personales que se tienen asociadas a un contrato.
• Autorizado: Objeto que hereda de persona y que representa las personas
que están autorizadas a utilizar un contrato en la videotienda.
• Afiliado: Objeto que hereda de persona y que representa al titular que creo
un contrato en la videotienda.
• Contrato: Objeto que sirve para representar una afiliación de una persona a
la videotienda.
• Factura: Sirve para representar los ingresos de la videotienda. Están
asociados a un contrato.
• Detalle factura: Sirve para representar los distintos rubros que pueden ser
cobrados en una factura.
• Rol: Objeto que sirve para representar los distintos tipos de usuarios que
tiene el sistema.

13
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

4. Capa DAO
La siguiente capa dentro de nuestra arquitectura es la capa DAO. Esta capa surge
de la necesidad de mantener la integridad de los datos que tenemos guardados en
la base de datos. Para esto, hemos decidido utilizar el patrón DAO, el cual sirve
para separar el acceso a los datos de capas como la de lógica de negocio o
presentación. Esto permite asegurar la integridad de nuestra base de datos y
poder tener un mayo mantenimiento dentro de nuestra aplicación.

Para nuestra aplicación, hemos decidido tener daos para afiliados, autorizados,
contratos, facturas, películas, referencias y roles. Todos ellos se encuentra dentro
del paquete Co.Edu.Javeriana.Fwj2ee.Dao de nuestra aplicación. A
continuaciones describirán las funciones de cada uno de esos DAO´s.

4.1 Afiliados

Este DAO se encarga de la creación, eliminación, modificación y lectura de los


afiliados que existan en la videotienda. Los procedimientos que ofrecerá son los
siguientes:

• public boolean crear( Afiliado Afiliado, int numeroContrato)


Este método servirá para la creación de nuevos afiliados a partir de un POJO
de Afiliado y el numero del contrato al cual esta asociado este afiliado.
Retornara un valor indicando si el afiliado se pudo o no crear.

• public boolean eliminar( Afiliado Afiliado)


Este método servirá para la eliminación de un afiliado a partir de un POJO de
Afiliado en el que estará solamente la información de la cedula de este.
Retornara un valor indicando si el afiliado se pudo borrar o no.

• public Set buscar( Afiliado Afiliado, int numeroContrato)


Este método servirá para la búsqueda de afiliados a partir de un POJO de
Afiliado en el que solo estará la información de los criterios de la búsqueda y/o
del contrato. Retornara un set con los POJO´s que cumplen con los criterios.
Puede ser vació.

• public boolean actualizar( Afiliado Afiliado, int numeroContrato)


Este método servirá para la actualización de la información de un afiliado a
partir de un POJO con la nueva información y del numero de contratos.
Retornara un valor indicando si la información se pudo actualizar.

14
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

4.2 autorizados

Este DAO se encarga de la creación, eliminación, modificación y lectura de los


autorizados que existan en la videotienda. Los procedimientos que ofrecerá son
los siguientes:

• public boolean crear( Autorizado autorizado, int numeroContrato)


Este método servirá para la creación de nuevos Autorizados a partir de un
POJO de Autorizado y el numero del contrato al cual esta asociado este
Autorizado. Retornara un valor indicando si el Autorizado se pudo o no crear.

• public boolean eliminar( Autorizado autorizado)


Este método servirá para la eliminación de un Autorizado a partir de un POJO
de Autorizado en el que estará solamente la información de la cedula de este.
Retornara un valor indicando si el Autorizado se pudo borrar o no.

• public Set buscar( Autorizado autorizado, int numeroContrato)


Este método servirá para la búsqueda de Autorizados a partir de un POJO de
Autorizado en el que solo estará la información de los criterios de la búsqueda
y/o del contrato. Retornara un set con los POJO´s que cumplen con los
criterios. Puede ser vacio.

• public boolean actualizar( Autorizado autorizado, int numeroContrato)


Este método servirá para la actualización de la información de un Autorizado a
partir de un POJO con la nueva información y del numero de contratos.
Retornara un valor indicando si la información se pudo actualizar.

4.3 Contratos

Este DAO se encarga de la creación, eliminación, modificación y lectura de los


contratos que existan en la videotienda. Los procedimientos que ofrecerá son los
siguientes:

• public boolean crear( Contrato Contrato)


Este método servirá para la creación de nuevos Contratos a partir de un POJO
de Contrato. Retornara un valor indicando si el Contrato se pudo o no crear.

• public boolean eliminar( Contrato Contrato)


Este método servirá para la eliminación de un Contrato a partir de un POJO de
Contrato. Retornara un valor indicando si el Contrato se pudo borrar o no.

15
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

• public Contrato buscar( Contrato Contrato)


Este método servirá para la búsqueda de Contratos a partir de un POJO de
Contrato. Retornara un Contrato con la información que corresponda o vacio.

• public boolean actualizar( Contrato Contrato)


Este método servirá para la actualización de la información de un Contrato a
partir de un POJO con la nueva información. Retornara un valor indicando si la
información se pudo actualizar.

4.5 Facturas

Este DAO se encarga de la creación, eliminación, modificación y lectura de las


facturas que existan en la videotienda. Los procedimientos que ofrecerá son los
siguientes:

• public boolean crear( Factura Factura)


Este método servirá para la creación de nuevos Facturas a partir de un POJO
de Factura. Retornara un valor indicando si la Factura se pudo o no crear.

• public boolean eliminar( Factura Factura)


Este método servirá para la eliminación de un Factura a partir de un POJO de
Factura. Retornara un valor indicando si la Factura se pudo borrar o no.

• public Set buscar( Factura Factura)


Este método servirá para la búsqueda de Facturas a partir de un POJO de
Factura. Retornara un Set de facturas con las que concuerden con la búsqueda
o vacio.

• public boolean actualizar( Factura Factura)


Este método servirá para la actualización de la información de una Factura a
partir de un POJO con la nueva información. Retornara un valor indicando si la
información se pudo actualizar.

16
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

4.6 Películas

Este DAO se encarga de la creación, eliminación, modificación y lectura de las


películas que existan en la videotienda. Los procedimientos que ofrecerá son los
siguientes:

• public boolean crear( Pelicula Pelicula)


Este método servirá para la creación de nuevos Películas a partir de un POJO
de Pelicula. Retornara un valor indicando si la Pelicula se pudo o no crear.

• public boolean eliminar( Pelicula Pelicula)


Este método servirá para la eliminación de un Pelicula a partir de un POJO de
Pelicula. Retornara un valor indicando si la Pelicula se pudo borrar o no.

• public Set buscar( Pelicula Pelicula)


Este método servirá para la búsqueda de Películas a partir de un POJO de
Pelicula. Retornara un Set de Películas con las que concuerden con la
búsqueda o vacio.

• public boolean actualizar( Pelicula Pelicula)


Este método servirá para la actualización de la información de una Pelicula a
partir de un POJO con la nueva información. Retornara un valor indicando si la
información se pudo actualizar.

4.7 Referencias

Este DAO se encarga de la creación, eliminación, modificación y lectura de las


referencias que existan en la videotienda. Los procedimientos que ofrecerá son los
siguientes:

• public boolean crear( Referencia Referencia, int numeroContrato)


Este método servirá para la creación de nuevas Referencias a partir de un
POJO de Referencia y el numero del contrato al cual esta asociado este
Referencia. Retornara un valor indicando si el Referencia se pudo o no crear.

• public boolean eliminar( Referencia Referencia)

17
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

Este método servirá para la eliminación de una Referencia a partir de un POJO


de Referencia en el que estará solamente la información de la cedula de este.
Retornara un valor indicando si el Referencia se pudo borrar o no.

• public Set buscar( Referencia Referencia, int numeroContrato)


Este método servirá para la búsqueda de Referencias a partir de un POJO de
Referencia en el que solo estará la información de los criterios de la búsqueda
y/o del contrato. Retornara un set con los POJO´s que cumplen con los
criterios. Puede ser vacio.

• public boolean actualizar( Referencia Referencia, int numeroContrato)


Este método servirá para la actualización de la información de una Referencia
a partir de un POJO con la nueva información y del numero de contratos.
Retornara un valor indicando si la información se pudo actualizar.

4.8 Roles

Este DAO se encarga de la creación, eliminación, modificación y lectura de los


roles que existan en la videotienda. Los procedimientos que ofrecerá son los
siguientes:

• public boolean crear( Rol Rol)


Este método servirá para la creación de nuevos Roles a partir de un POJO de
Rol. Retornara un valor indicando si el Rol se pudo o no crear.

• public boolean eliminar( Rol Rol)


Este método servirá para la eliminación de un Rol a partir de un POJO de Rol.
Retornara un valor indicando si el Rol se pudo borrar o no.

• public Rol buscar( Rol Rol)


Este método servirá para la búsqueda de Roles a partir de un POJO de Rol.
Retornara un Rol con la información que corresponda o vacio.

• public boolean actualizar( Rol Rol)


Este método servirá para la actualización de la información de un Rol a partir
de un POJO con la nueva información. Retornara un valor indicando si la
información se pudo actualizar.

18
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

5. Capa de servicios
La siguiente capa dentro de nuestra arquitectura es la capa de servicios. Esta
capa es la encargada de manejar toda la lógica del negocio, proveyendo a las
capas superiores todas las funcionalidades que fueron descritas para el sistema.

Los servicios los hemos agrupado según los elementos que estén implicados
dentro de este, los grupos que hemos definido son: contratos, películas, facturas y
reportes.

A continuación se definirán cada unote los servicios que ofrecerán estos grupos.

5.1 Contratos
Dentro del grupo de los servicios ofrecidos para los contratos se han definido los
siguientes:

5.1.1 Crear contratos

Precondición: Haber ingresado al sistema exitosamente.


Poscondición: Se creara un nuevo registro en la base de datos de un nuevo
contrato, asociándole el afiliado y sus referencias.
Definición: El sistema deberá ofrecer el servicio de la creación de contratos. Para
esto se deberán gestionar los POJO`s de personas y contratos por medio de una
clase que maneje el patrón DAO. Para realizar esta transacción se deben recibir
como parámetros la fecha de creación del contrato, las personas que son
beneficiarias de un contrato, cual de estas personas fue la que creo el contrato y
las referencias personales asociadas. El sistema deberá crear en la base de datos
un nuevo contrato y asociarle a este todos los beneficiarios que se recibieron
como parámetro.
Prototipo: public boolean crearContrato(Contrato contrato, Afiliado afiliado, Set
referencias)

5.1.2 Eliminar contratos (desafiliar)

Precondición: Haber ingresado al sistema exitosamente, y conocer el numero del


contrato a eliminar.
Poscondición: Se eliminara un registro en la base de datos de un contrato con
todos las personas que dependen de este.
Definición: El sistema deberá ofrecer el servicio de la eliminación de contratos.
Para realizar esta transacción se deben recibir como parámetro el número del
contrato que se debe eliminar. El sistema deberá ejecutar sentencias de HSQL

19
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

donde se borre la información del contrato y de todos los beneficiarios asociados a


este.
Prototipo: public boolean eliminarContrato(Contrato contrato)

5.1.3 consultar contratos

Precondición: Haber ingresado al sistema exitosamente, y conocer el numero del


contrato a consultar. El contrato debe existir.
Poscondición: se retornara el POJO del contrato asociado.
Definición: El sistema deberá ofrecer el servicio de la consulta de contratos. Para
realizar esta transacción se deben recibir como parámetro la información del
contrato que se quiere consultar. El sistema deberá ejecutar sentencias de HSQL
donde se consulte la información del contrato y retornara un POJO del contrato
asociado.
Prototipo: public Contrato consultarContrato(Contrato contrato)

5.1.4 Agregar Autorizado


Precondición: Haber ingresado al menú de Afiliaciones determinando una
especifica.
Poscondición: Se creara un nuevo registro en la base de datos de un nuevo
Autorizado para el contrato asociado.
Definición: El sistema debe ofrecer el servicio de agregar autorizados a un
contrato. Para realizar esta transacción se deben recibir como parámetros la
información de la persona que se quiere autorizar y el número del contrato al cual
se quiere asociar la persona. El sistema debe guardar la información de la persona
en la base de datos asociándola al contrato que corresponda.
Prototipo: public bolean agregarAutorizado(Autorizado autorizado, Contrato
contrato)

5.1.4 Eliminar Autorizado


Precondición: Haber ingresado al menú de contratos y buscar el contrato para el
que quiere eliminar el autorizado.
Poscondición: Se eliminara registro en la base de datos de un Autorizado para el
contrato asociado.
Definición: El sistema debe ofrecer el servicio de eliminar autorizados a un
contrato. Para realizar esta transacción se deben recibir como parámetros la
información de la persona que se quiere desautorizar y el número del contrato al
cual esta asociadola persona. El sistema debe eliminar la información de la
persona en la base de datos.
Prototipo: public bolean eliminarAutorizado(Autorizado autorizado, Contrato
contrato)

20
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

5.1.5 Actualización de afiliados


Precondición: Haber ingresado al sistema exitosamente, solo se podrán
actualizar los datos del afiliado.
Poscondición: Se actualizara un registro en la base de datos de un afiliado.
Definición: Para la actualización de los afiliados se debe recibir un POJO con la
información actualizada que se quiere tener del afiliado. El sistema deberá salvar
el POJO con la nueva información en la base de datos verificando que esta no
viole la integridad respecto a las otras personas que se tienen.
Prototipo: public bolean actualizarAfiliado(Afiliado afiliado, Contrato contrato)

5.1.6 Actualización de autorizados


Precondición: Haber ingresado al sistema exitosamente, solo se podrán
actualizar los datos del autorizado.
Poscondición: Se actualizara un registro en la base de datos de un autorizado.
Definición: Para la actualización de los autorizados se debe recibir un POJO con
la información actualizada que se quiere tener del autorizado. El sistema deberá
salvar el POJO con la nueva información en la base de datos verificando que esta
no viole la integridad respecto a las otras personas que se tienen.
Prototipo: public bolean actualizarAutorizado(Autorizado autorizado, Contrato
contrato)

5.2 Películas
Dentro del grupo de los servicios ofrecidos para las películas se han definido los
siguientes:

5.2.1 Creación Películas:


Precondición: Haber ingresado al sistema exitosamente y estar en el menú de
Configuración de Películas.
Poscondición: Se creara un nuevo registro en la base de datos de una nueva
película con sus respectivos atributos.
Definición: Para la creación de películas se deberá recibir toda la información
relacionada a una película (nombre, año, duración, caja, etc.). El sistema deberá
verificar que la película no exista y creara una nueva película con la información
que se recibió en la base de datos.
Prototipo: public bolean crearPelicula(Película película)

5.2.2 Consulta de Películas:


Precondición: Haber ingresado al sistema exitosamente y estar en el menú de
Configuración de Películas.
Poscondición: Se mostrara en la pantalla una lista de las películas con todos sus
detalles , asociadas a los criterios de búsqueda.

21
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

Definición: Para la lectura de películas se debe recibir los criterios que debe tener
la película que se quiere leer. El sistema deberá realizar una búsqueda con HSQL
según los criterios que se reciban y deberá retornar el(los) POJO que
corresponda.
Prototipo: public Set consultarPelicula(Película película)

5.2.3 Actualización de Películas:


Precondición: Haber ingresado al sistema exitosamente y estar en el menú de
Configuración de Películas.
Poscondición: Se actualizara un registro en la base de datos de una película
configurando alguno de sus atributos.
Definición: Para la actualización de las películas se debe recibir un POJO con la
información actualizada que se quiere tener de una película. El sistema deberá
salvar el POJO con la nueva información en la base de datos verificando que esta
no viole la integridad respecto a otras películas que se tengan.
Prototipo: public bolean actualizarPelicula(Película película)

5.2.4 Eliminar Películas:


Precondición: Haber ingresado al sistema exitosamente y estar en el menú de
Configuración de Películas.
Poscondición: Se eliminara un registro en la base de datos de una película.
Definición: Para el borrado de películas se deben recibir los criterios de
eliminación de una película. El sistema deberá ejecutar una sentencia de HSQL
que realizara la eliminación de la película en la base de datos.
Prototipo: public boolean eliminarPelicula(Película película)

5.2.5 Alquilar películas


Precondición: Haber ingresado al sistema exitosamente, conocer los id de las
películas.
Poscondición: Se registrara en la base de datos el nuevo estado de las películas,
adicionalmente se realiza el servicio de Crear factura, con sus atributos
respectivos.
Definición: El sistema debe ofrecer el servicio de alquilar películas. Para realizar
esta transacción el sistema debe recibir la información de la película que se va a
alquilar y del contrato al que se le va a cargar la película, luego se deben guardar
referencias en la base de datos de la película que se va a alquilar por medio de la
creación de una factura asociada a este alquiler.
Prototipo: public boolean alquilarPelicula(Película película, Contrato contrato)

22
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

5.2.6 Entrega películas


Precondición: Haber ingresado al sistema exitosamente, conocer los id de las
películas.
Poscondición: Se registrara en la base de datos el nuevo estado de las películas,
adicionalmente se realiza el servicio de Crear factura si esta acción genera una
multa.
Definición: El sistema debe ofrecer el servicio de la entrega de películas y
generación automática de multas. Para realizar estas operaciones el sistema debe
recibir la información de la película y la fecha en que es entregada, con esta
información se debe dejar como disponible la película. Luego se debe hacer una
verificación de si la película fue entregada en el plazo establecido, de no ser así se
debe generar una factura para el pago de la multa y esta debe ser guardada como
no pagada dentro del sistema.
Prototipo: public boolean entregarPelicula(Película película, Contrato contrato)

5.3 Facturas
Dentro del grupo de los servicios ofrecidos para las facturas se han definido los
siguientes:

5.3.1 Creación de Facturas:


Precondición: Haber ingresado al sistema exitosamente, y estar en el servicio de
Alquiler de Películas.
Poscondición: Se creara un nuevo registro en la base de datos de una nueva
factura con sus respectivos detalles y costos.
Definición: Para la creación de facturas se deberá recibir toda la información
relacionada a una factura (fecha, valor, descripción, etc.). El sistema deberá
verificar que la factura no exista y creara una nueva factura con la información que
se recibió en la base de datos.
Prototipo: public boolean crearFactura(Factura factura, Contrato contrato)

5.3.2 Consultar Facturas:


Precondición: Haber ingresado al sistema exitosamente. y estar en el menú de
Configuración de Facturas.
Poscondición: Se mostrara en pantalla una lista de facturas según los criterios de
búsqueda.
Definición: Para la lectura de facturas se debe recibir los criterios que debe tener
la factura que se quiere leer. El sistema deberá realizar una búsqueda con HSQL
según los criterios que se reciban y deberá retornar el POJO que corresponda.
Prototipo: public void consultarFactura(Factura factura, Contrato contrato)

23
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

5.3.3 Eliminar Facturas:


Precondición: Haber ingresado al sistema exitosamente, la factura ha eliminar no
ha sido pagada y se eliminara por un caso extraordinario, se debe conocer el id de
la factura.
Poscondición: Se eliminara un registro en la base de datos de una factura con
sus respectivos detalles y costos.
Definición: Para el borrado de facturas se deben recibir los criterios de
eliminación de una factura. El sistema deberá ejecutar una sentencia de HSQL
que realizara la eliminación de la factura en la base de datos.
Prototipo: public bolean eliminarFactura(Factura factura)

5.4 Reportes
Dentro del grupo de los servicios ofrecidos para los reportes se han definido los
siguientes:

5.4.1 Películas prestadas en un rango de fechas.


Precondición: Haber ingresado al sistema como administrador exitosamente.
Poscondición: Se retornara un Set de todas las películas prestadas en el rango
que se ingreso como parámetro.
Definición: Para generar un reporte de las películas prestadas en un rango de
fechas se deben recibir las fechas de inicio y final del rango. El sistema deberá
realizar una consulta en HSQL según estas fechas y deberá retornar una
colección con la información correspondiente a las películas alquiladas en este
rango.
Prototipo: public Set películasPrestadas(Date fi, Date ff)

5.4.2 Películas en mora a la fecha.


Precondición: Haber ingresado al sistema como administrador exitosamente.
Poscondición: se retornara un Set de todas las películas que están en mora a la
fecha
Definición: Para generar el reporte de las películas en mora a la fecha el sistema
deberá realizar una consulta en HSQL según la fecha del día y deberá retornar
una colección con la información de las películas en mora a una fecha.
Prototipo: public Set peliculasEnMora()

5.4.3 Facturas emitidas en un rango de fechas


Precondición: Haber ingresado al sistema como administrador exitosamente.
Poscondición: se retornara un Set de todas las facturas que fueron emitidas en el
rango de fechas que se ingreso como parámetro.
Definición: Para generar reporte de las facturas emitidas en un rango de fechas
se deberá recibir la información de las fechas de inicio y final del rango. El sistema
deberá realizar una consulta en HSQL según estos valores y deberá retornar una
colección con la información de las facturas en este rango.
Prototipo: public Set facturasEmitidas(Date fi, Date ff)

24
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

5.4.4 Clientes en mora


Precondición: Haber ingresado al sistema como administrador exitosamente.
Poscondición: se retornara un Set con los clientes que están en mora a la fecha.
Definición: Para generar reporte de los clientes en mora el sistema no recibe
ningún parámetro. El sistema debe realizar una consulta en HSQL de las facturas
que no han sido pagadas y deberá retornar una colección de los clientes que no
han pagado.
Prototipo: public Set clientesEnMora()

25
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

6. Capa de interfaz
Finalmente, utilizando todas las capas que se definieron bajo ella se encuentra la
capa de interfaz o de presentación, esta es la encargada de interactuar con el
usuario, por ello se debe tener especial cuidado para desarrollarla.

Para nuestro proyecto, esta interfaz va a estar desarrollada sobre J2EE, que es la
finalidad de este proyecto de grado. Por eso posteriormente se realizara un nuevo
documento donde se especifiquen todos los elementos de diseño que debe tener
esta capa, luego de que se profundice mas en este tema.

La definición de las interfaces para nuestro sistema esta en el documento


Descripción de Pantallas; Para mayor información al respecto remítase a este
documento.

26
Framework unificado para desarrollo de interfaces J2EE
Documento de Arquitectura y Servicios
Versión 0.1

7. Conclusiones
Con la realización de este documento, se han definido claramente las capas sobre
las cuales se basara nuestra aplicación de prueba, que de manera mas general,
serán las mismas sobre las cuales se enmarca el desarrollo de este proyecto de
grado. Esto permitió que se defina de mejor manera las funcionalidades de cada
una de estas capas, lo cual permite el desarrollo de un mejor diseño.

Esta claro que ahora nos debemos preocuparnos por conocer mas de la ultima
capa de nuestra arquitectura, la capa de interfaz, por que es esta la piedra angular
de nuestro proyecto. Con el transcurso del proyecto, este documento se ira
depurando, lo que nos permitirá establecer elementos importantes para la
definición de la metodología sobre la cual queremos trabajar.

27

Vous aimerez peut-être aussi