Caso Arquitectura.pdf

Capítulo 6

Caso de estudio: Sistema de Cheques

Tomaremos como caso de estudio los lineamientos fundamentales de la operatoria que deben realizar los Bancos para la implementación de un nuevo sistema en la gestión de cobro de Cheques.

Este sistema permite la captura descentralizada de cheques de cualquier importe, eliminándose en todo el país el traslado físico de los mismos, quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captación y su domicilio de pago.

Las Entidades deben contar en cada una de sus sucursales con los medios necesarios para poder llevar a cabo la captura de los datos de los cheques depositados, la generación de los registros electrónicos y sus respectivas imágenes (digitalización). Transmitiéndose los registros electrónicos y las imágenes de los cheques superiores a un importe determinado.

Participantes

Los distintos participantes en el sistema son los que a continuación se detallan:

Participantes Internos al sistema:

- Las Sucursales de la Entidad Depositaria: Son quienes efectúan la digitalización y carga de todos los datos correspondientes al cheque depositado por el cliente en caja.

- Entidad Girada: Es quien recibe la información electrónica de los cheques, y previa verificación de la misma, debita el importe a sus clientes libradores y abona a la Entidad Depositaria.

Participantes Externos al sistema

- Cámara Compensadora: Es la administradora de la compensación electrónica de medios de pagos y sus funciones se detallan a continuación:

! Refundición de los archivos recibidos de las Entidades Depositarias y clasificación de éstos por Entidad Girada, generando los archivos con el detalle de transacciones para su posterior envío

! Refundición de los archivos de rechazos recibidos de las Entidades Giradas y la clasificación de éstos por Entidad Depositaria, generando los archivos conteniendo el detalle de las operaciones para su posterior envío.

Arquitectura de Software: Estilos y Patrones

Adriana Almeira – Vanina Perez Cavenago

Pag 79

Esquema Operativo

Los diagramas muestran la forma en la que participan cada uno de los integrantes del sistema:

Esquema a gran escala:

Suc 1

Entidad Depositaria /

Girada

Suc 4

Suc 3Suc 2

Entidad Depositaria /

GiradaCamara

Compensadora

Suc 1

Suc 4

Suc 3Suc 2

Figura 6.1 - Esquema a gran escala

Esquema solución dentro de cada Entidad:

Cámara

Compensadora

CASA MATRIZ

Server de la SucursalSistema de Escaneo

de Cheques

Suc 2

Sistema de Escaneo

de Cheques

Sistema de Escaneo

de Cheques

Suc 4

Server de la Sucursal

Sistema de Escaneo

de Cheques

Servidor Central

Entidad Depositaria / Girada

Suc 1

Suc 3

Host_Central

Sistema Centralizador

Sistema de Escaneo

de Cheques

Sistema de Escaneo

de Cheques Sistema de Escaneo

de Cheques


Sistema de Escaneo

de Cheques


Figura 6.2 - Esquema dentro de cada una de las entidades.



Pag 80

Definición del Sistema

Podemos especificar tres grandes circuitos que consisten en el envío/recepción diario de archivos a la Cámara Compensadora donde se encuadran cada una de las sesiones, denominando sesión al proceso de envío o recepción de archivos desde/hacia la Cámara Compensadora, correspondiente a cada ítem de cada uno de los circuitos.

Circuito de Cheques

Las Entidades transmitirán a la Cámara Compensadora archivos conteniendo los registros electrónicos correspondiente a los cheques que dicha Entidad presenta para su compensación electrónica en sesiones diariamente. Se entiende por registro electrónico al conjunto de datos que definen a un cheque - banco, sucursal, código postal, número de cheque, número de cuenta, importe y fecha.

En el circuito de cheques enviados, los cheques son escaneados en las sucursales, una vez realizado el cierre son remitidos al Sistema Centralizador (registros electrónicos e imágenes), donde se gestionan los distintos archivos para su posterior envío.

Respecto al envío de archivos se identifican tres sesiones.

- Cheques: Corresponde a la generación de un archivo conteniendo los registros electrónicos de los cheques.

- Imágenes: Se genera un archivo conteniendo todas la imágenes correspondientes a los cheques escaneados en el día, que superen un importe determinado.

- Rechazos de Cheques: Luego de imputar los cheques recibidos, capturados en otros bancos el día anterior, se genera un archivo conteniendo aquellos cheques que se necesitan rechazar, es decir que no se pagan por diversos motivos (Ej: Sin fondo, Cuenta Inexistente, Falla Técnica, etc.).

En el circuito de cheques recibidos, los archivos están conformados por cheques que han sido capturados en otros bancos el día anterior y son recibidos para su imputación en sus respectivas cuentas.

Respecto a la recepción de archivos se identifican tres sesiones.

- Cheques Recibidos: Se recepciona y procesa un archivo conteniendo los registros electrónicos de cheques procedentes de otros bancos para su cobro.

- Imágenes: Se recepciona y procesa un archivo con todas las imágenes de los cheques que han sido capturados en otros bancos.

- Rechazos de Cheques: Se recepciona y procesa un archivo con los registros electrónicos de los cheques rechazados por la Entidad Girada. Estos rechazos corresponden a cheques enviados por la Entidad Depositaria anteriormente.



Pag 81

Entidad Girada Entidad

Depositaria

Camara

Compensadora

Presentación de Cheques Recepción de Cheques

Recepción de Rechazos Rechazo de Cheques

Presentación de Imágenes Recepción de Imagenes

Figura 6.3 - Esquema dentro de cada una de las entidades.

Circuito de Imágenes por Rechazo

Luego del proceso de recepción de los cheques y su imputación contable, se genera el archivo de Cheques rechazados. Para indicar el rechazo de un cheque, se asocia a su registro electrónico un código de rechazo. Dependiendo del código de rechazo, la Entidad Depositaria deberá enviar, o no, a la Entidad Girada la imagen del mismo.

El envío de los archivos se realiza por diferentes sesiones:

- Imágenes por rechazo: Una vez recibidos los archivos de rechazos se deberá enviar a la Entidad Girada las imágenes de aquellos cheques que según su código de rechazo lo requieran.

- Rechazo de Imágenes por rechazo: En caso de recibir imágenes de una Entidad Depositaria que no correspondan a los cheques rechazados oportunamente, se deberá generar un archivo indicando el rechazo de la imagen.

La recepción de los archivos se realiza por diferentes sesiones:

- Imágenes por Rechazo: Una vez enviados los archivos de rechazos a la Entidad Depositaria, se deberá recibir de la misma, un archivo conteniendo las imágenes correspondientes a los cheques rechazados por los códigos que generan envío de imagen.

- Rechazo de Imágenes por rechazo: En esta sesión se recibirán rechazos de aquellas imágenes que se enviaron por rechazo y no se corresponden con los datos del registro electrónico del cheque rechazado.


Depositaria

Camara

Compensadora

Presentación de Rechazos Recepción de Rechazos

Recepción de Rechazos

Recepción de Imagenes

Rechazo de Imagenes

Rechazo de Rechazo

Presentación de Imágenes

Recepción de Rechazo de

Imágenes

Figura 6.4 - Circuito de Imágenes por rechazo



Pag 82

Circuito de Imágenes por Reclamos

El circuito de intercambio de imágenes por reclamo de cheques, es similar al que se usa en el circuito de imágenes de cheques rechazados.

Los reclamos se efectúan sobre cheques recibidos que, al gestionar su cobro no se contaba con la imagen. Esta operación es solicitada por el cliente librador del cheque.

Mediante diferentes sesiones se gestiona el envío de los archivos:

- Reclamos de cheques: Se genera un archivo conteniendo todos los registros electrónicos correspondientes a reclamos efectuados en sucursales.

- Imágenes por reclamo: Se genera un archivo con todas las imágenes correspondientes a los reclamos recibidos.

- Rechazo de Imágenes por reclamo: en caso de recibir imágenes de la Entidad Depositaria que no corresponden a los cheques reclamados, se genera un archivo indicando el rechazo de la imagen.

La recepción de los archivos se realiza por diferentes sesiones:

- Cheques reclamados: Se procesa el archivo conteniendo los registros electrónicos que indican las imágenes reclamadas que se deben enviar.

- Imágenes por reclamo: Se procesa el archivo que contiene las imágenes correspondientes a los cheques reclamados.

- Rechazo de Imágenes por reclamo: Se procesa el archivo que indica que se han enviado imágenes que no se correspondían con los reclamos recibidos.


Depositaria

Camara

Compensadora

Presentación de Reclamos Recepción de Reclamos

Recepción de Rechazos

Recepción de Imagenes

Rechazo de Imagenes

Rechazo de Reclamos

Presentación de Imágenes

Recepción de Rechazo de

Imágenes

Figura 6.5 - Circuito de Imágenes por reclamo

Limites del sistema

El caso de estudio se limita a realizar el análisis y diseño arquitectónico del sistema correspondiente a la captura descentralizada de los cheques en sucursales de las Entidades Depositarias y la recepción/envío de la información desde/al Host Central en Casa Matriz, el cual será el responsable de gestionar la comunicación con la Cámara Compensadora a través del Servidor Central.



Pag 83

Visión Arquitectónica

Realizando un diagnóstico del sistema de estudio consideramos que se ajusta a un esquema distribuido e interactivo.

Distribuido:

- El sistema está distribuido sobre una intranet en la Entidad Bancaria. La Entidad Bancaria cuenta con sucursales geográficamente separadas y con diferentes tecnologías de comunicación.

- El núcleo de la funcionalidad se encuentra en un Servidor Central ubicado en Casa Matriz.

- Las sucursales acceden a esta funcionalidad por medio de PCs.

Interactivo:

- Aplicación instalada en sucursales.

- Variedad de tipos de interfaz de usuario.

- Formularios, menús, cajas de diálogos, para interacción basada en eventos.

Independencia de plataformas

- Distintos servidores de base de datos, clientes con diferentes sistemas operativos.

Para realizar la definición de la arquitectura de base que capture toda la estructura de los subsistemas fundamentales de la aplicación, como primer paso, debemos definir la infraestructura identificando las propiedades de todo el sistema global, Distribuido e Interactivo, es decir:

- Seleccionar los patrones arquitectónicos adecuados.

- Combinar los patrones arquitectónicos seleccionados.

- Identificar los subsistemas funcionales: Utilizar los métodos de análisis y diseño convencional.

- Integrar los subsistemas funcionales con la infraestructura del sistema



Pag 84

Capítulo 7

Aplicación de Patrones

En este capítulo nos proponemos identificar patrones arquitectónicos y definir microarquitecturas y modelos de diseño basados en objetos, que permitan modelar el sistema anteriormente descripto de modo que resulte una aplicación extensible, fácil de modificar, mantener y reusar.

Se presenta el análisis y diseño realizado para nuestro trabajo, describiendo especialmente los patrones utilizados y las razones de su selección.

Análisis

En la presente sección se describirá el análisis del sistema. Esta etapa comienza con el estudio del proceso de gestión de cobro de cheques en el sistema bancario.

Como se mencionara en el capítulo anterior, este sistema permite la captura descentralizada de cheques de cualquier importe, eliminándose en todo el país el traslado físico de los mismos, quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captación y su domicilio de pago.

La Entidad Depositaria presenta cheques para su posterior cobro a la Entidad Girada donde se ha librado el valor. La Entidad Depositaria procesa en sus aplicativos esta transacción y efectúa el envío de la información electrónica a la Cámara Compensadora, quien separa y distribuye los archivos a las Entidades Giradas, las cuales, recibirán los archivos y se encargaran de impactar los movimientos de los cheques en las cuentas libradoras

A continuación se verá con más detalle el comportamiento de cada uno de los circuitos antes mencionados en forma integrada, posibilitando ver claramente cada una de las sesiones dependiendo de la Entidad que lo realiza (Depositaria/Girada) y como es la relación entre ellas.

La figura 7.1 representa el flujo de datos entre las entidades involucradas correspondiente al circuito de escaneo de cheques en conjunto con el circuito de imágenes por rechazo.



Pag 85

Entidad Girada

Imputación de cheques

(Debito)

Recepción y procesamiento de

archivo de cheques escaneados

Generación de cheques

rechazados

No

Si

Imputación de cheques (Crédito)

Recepción de cheques

rechazados

Escaneo de cheques

Imputación de cheques (Crédito y

Debito)

Generación de archivo con

imágenes por rechazo

Recepción y procesamiento de

Imágenes por rechazo

Chequear imagen en

Sucursal

Aceptación de

imagen

SiNo

Generar rechazo de imágenes

por rechazo

Procesar rechazo de imágenes

por rechazo

Si

No

No

SI

Generación y envío de archivo de

cheques escaneados

Búsqueda de la imagen

correspondiente al cheque rechazado

Marcar rechazo de reclamo

Cheque rechazado?

Código de

rechazo genera imagen?

Corresponde

imagen?

Imagen válida

para sucursal?

Entidad Depositaria

Deposito por Caja

Registración del

Cheque

Si es Cheque

propio

No

Si

Pago o Rechazo según saldo suficiente

Si

Figura 7.1 - Circuito de Depósito de Cheques

El proceso comienza con el depósito en la Entidad Depositaria del o los cheques por parte del cliente. De esta forma el cheque entra en el circuito para gestionar su cobro, cambiando su estado a lo largo del mismo.

La Entidad Depositaria es la responsable de realizar la digitalización de todos los cheques así como la integración de sus datos. Una vez concluida esta tarea, en forma



Pag 86

centralizada se genera el archivo conteniendo todos los cheques a enviar a la Entidad Girada. Una vez aquí, se recepciona, se procesa el archivo y se realiza su imputación monetaria, efectuando los débitos en las cuentas corrientes correspondientes. Como consecuencia de este proceso, se plantean dos situaciones, el cheque puede ser rechazado o aceptado:

- Aceptado: en este caso, la Entidad Depositaria al día siguiente al no recibir rechazo, procede a la acreditación del importe del cheque en la cuenta depositaria correspondiente. Concluyendo de esta manera con el circuito de digitalización de cheques.

- Rechazado: La Entidad Girada genera un archivo conteniendo todos los cheques que desea informar como rechazados, con sus respectivos códigos de rechazo, y lo envía a la Entidad Depositaria.

La Entidad Depositaria al recibir los cheques rechazados debe reflejar estos en las respectivas cuentas de los clientes depositantes, impactando un movimiento de débito y un movimiento de crédito, mostrando de esta manera el ingreso de los cheques al circuito y su posterior rechazo.

La tarea posterior a la imputación monetaria de los cheques rechazados es analizar su código de rechazo asociado. En caso de:

- Código de rechazo que no genera imagen: Concluye el circuito de cheques rechazados.

- Código de rechazo que si genera imagen: Se buscan las imágenes correspondientes a los cheques que se han rechazado, se genera un archivo y se envía a la Entidad Girada.

La Entidad Girada cuando recibe el archivo con imágenes por rechazo debe arbitrar los medios para efectuar la recepción y procesamiento del mismo, donde debe chequear si corresponden a imágenes de cheques rechazados:

- Si corresponden a cheques rechazados se envía a la sucursal para su chequeo visual.

- Si no corresponden a cheques rechazados, se genera en forma automática el rechazo de la imagen.

Una vez que las imágenes se encuentran en la sucursal, se realiza el chequeo visual de las mismas.

- En caso de poder contar con la imagen sin problemas de visualización se acepta la imagen dando por concluido el circuito de rechazos.

- En caso de tener algún problema de visualización, por ejemplo, imagen ilegible, cheque mal escaneado, etc, la sucursal marcará dicha imagen como rechazada.

Una vez obtenidos todos los rechazos, ya sea en forma automática o porque una sucursal la marcó, se genera el archivo de rechazo de imágenes por rechazo, el cual es enviado a la Entidad Depositaria.



Pag 87

La Entidad Girada recibe y procesa dicho archivo. De esta manera se concluye con el circuito de imágenes por rechazo.

Como vemos en este último caso, nos encontramos en la situación en que la Entidad Girada aún no cuenta con las imágenes de los cheques que ha rechazado. Como consecuencia de ellos existe a disposición de esta entidad la posibilidad de efectuar reclamos sobre los cheques que ha recibido.

En la siguiente figura 7.2 se muestra dicho circuito.

No

Si

No

Si

Si

Verificación de reclamos

Recepción y procesamiento de archivo

de reclamos

Realizar reclamo en

sucursal

Generar archivo de reclamo

Cheque enviado?

Buscar imagen correspondiente al

cheque reclamadoGenerar rechazo de reclamo

Generar archivo con imagen

Recibir rechazo de reclamos

Recibir archivo con imágenes

por cheques reclamados

Corresponde la

imagen?

Controlar imagen en

sucursal

Imagen válida para

sucursal?

Generar rechazo de imágenes

por reclamo

Procesar rechazo de imágenes

por reclamo

No

Entidad GiradaEntidad Depositaria

Marcar rechazo

Figura 7.2 - Circuito de Reclamos de Cheques



Pag 88

La posibilidad de efectuar reclamos se puede realizar sobre cualquier tipo de cheque recibido, tanto aceptado como rechazado. Los reclamos sirven para obtener las imágenes de aquellos cheques cuyo importe sea inferior al importe predefinido para el envío de imágenes del circuito de cheques.

La Entidad Girada es la única que puede realizar reclamos respecto de los cheques que ha recibido. Comienza en las sucursales quienes son las encargadas de realizar los reclamos, luego en forma centralizada se genera un archivo y se envían a la Entidad Depositaria.

Una vez que la Entidad Depositaria ha recibido y procesado el archivo se verifica que el reclamo corresponda a un cheque escaneado y enviado por ésta:

- Si el reclamo no corresponde a un cheque enviado, se marca en forma automática el reclamo con un nuevo código de rechazo, se genera un archivo conteniendo los rechazos de imágenes por reclamo y se envía a la Entidad Girada. Al recibir el archivo la Entidad Girada, lo procesa y da por concluido el circuito de reclamos.

- Si el reclamo corresponde a un cheque enviado, se busca la imagen asociada a este y se genera un archivo con todas las imágenes y se envía a la otra entidad.

La Entidad Girada cuando recibe el archivo con imágenes por reclamo efectúa la recepción y procesamiento del mismo, donde chequea si corresponde a los reclamos efectuados:

- Si corresponden a cheques reclamados se envía a la sucursal para su verificación visual.

- Si no corresponden a cheques reclamados, se genera en forma automática el rechazo de la imagen.

Una vez en la sucursal, se realiza la verificación de las mismas.

- Si se puede visualizar correctamente, se acepta la imagen y se da por finalizado el circuito de reclamos.

- Si tiene errores al visualizarse, como por ejemplo imagen ilegible, cheque mal escaneado, etc, se marca dicha imagen como rechazada.

Una vez que se marcan todos los rechazos, ya sea en forma automática o porque una sucursal la marcó, se genera el archivo de rechazo de imágenes por reclamo, el que es enviado a la Entidad Depositaria.

La Entidad Depositaria recibe y procesa dichos rechazos, concluyendo con el circuito de imágenes por reclamo.

Modelo de casos de uso

Con la información obtenida a partir de las circuitos descriptos de escaneo de cheques, rechazos y reclamos se definen los actores y los casos de uso involucrados en los procesos para finalizar con las restricciones generales que debe cumplir el sistema.



Pag 89

En los procesos se identifican dos actores: Usuario y Sistema Centralizador. El primero representa a los usuarios que realizan el escaneo y la carga de los cheques en sucursales y el segundo representa al Sistema Central que gestiona la información de todas las sucursales.

Para que un usuario pueda acceder al sistema deberá identificarse previamente, una vez autenticado podrá tener acceso a la información (registro electrónico y/o imagen) e ingresar nuevos cheques.

Con estas funcionalidades definidas, el sistema estará compuesto por los siguientes grupos de casos de uso:

Validación:

- Validar el ingreso correcto de un actor al sistema a través de su nombre de usuario y su password y obtener la fecha en forma centralizada.

- Verificación y validación de números de cuentas depositarias en el momento del depósito del cheque.

- Verificación si corresponde a un cheque propio o un cheque de otra sucursal u otro banco.

Apertura y cierre de operaciones:

- Realizar la apertura del día en la Sucursal: Se reciben archivos del sistema centralizador:

! Cheques Presentados

! Cheques rechazados recibidos

! Reclamos recibidos

- Realizar el cierre del día provocando la generación y envío de los archivos correspondientes a

! Cheques depositados

! Reclamos enviados

! Rechazos enviados

Búsqueda de información: (Utilizado por el usuario)

- Desplegar la información existente en la base de datos. Permitir ver sólo los registros electrónicos/imagen de los cheques ingresados al sistema por esa sucursal y aquellos cheques que fuesen enviados a esa sucursal para gestionar su cobro.

- Listados de Cheques ingresados al sistema.

- Cheques Recibidos con visualización de su imagen.

- Cheques Enviados con visualización de su imagen.

- Consultar la historia de un cheque (recibido, enviado, aceptado, rechazado, envío de imágenes por reclamo/rechazo, recepción de imágenes por reclamo/rechazo).



Pag 90

Depósito de cheques: (Utilizado por el usuario):

- Depósito y digitalización de cheques: Esta tarea se realiza en el momento que el cliente se presenta por caja y efectúa el depósito del cheque. En caso de se un cheque propio el mismo se registra y es pagado o no por caja, caso contrario, si es un cheque que pertenece a otra sucursal o a otro banco el cheque es digitalizado con escaners especiales que capturan en forma automática los datos de los cheques (banco, sucursal, código postal, número de cheque y número de cuenta) por lo que resta la integración manual por parte del usuario del número de cuenta depositaria e importe del cheque depositado. En este proceso la imagen capturada del cheque se asocia al registro electrónico del mismo definiendo en él, path y nombre del archivo físico de la imagen.

Administración de datos: tener a disposición ABM que permitan

- ABM de Reclamos

- Generar Rechazos de Imágenes recibidas por Reclamos

- Generar Rechazos de Imágenes recibidas por Rechazos

Validación

Usuario Sistema

Centralizador

Sistema de Escaneo

de Cheques

Búsqueda de Información

Depósito de Cheques

Administración de datos

Apertura y cierre de operaciones

Figura 7.3 - Diagrama de casos de uso



Pag 91

Diseño

El Modelo Arquitectónico

El objetivo principal del diseño arquitectónico es representar componentes que interactúen entre ellos y tener asignadas tareas específicas, ser flexible y extensible y representar las relaciones de control entre las partes.

El sistema en estudio tiene el comportamiento de un sistema Distribuido e Interactivo como ya lo mencionamos. Los cuales se ajustan a los siguientes patrones arquitectónicos:

- Patrón Broker: Soporta la distribución y la integración de componentes. Nos interesa que la aplicación que usa un objeto lo haga a través de la interfaz ofrecida por ese objeto, despreocupándose de los detalles de su implementación o su ubicación física y que las invocaciones de servicios remotos sean transparentes respecto de su ubicación.

Cproxy

ServidorCliente

SproxyBroker

Figura 7.4 - Patrón Broker

Para el diseño de aplicaciones con interfaces gráficas se utiliza el patrón Model-View-Controller. La lógica de una interfaz de usuario cambia con más frecuencia que los almacenamientos de datos y la lógica de negocio. Si se realiza un gran diseño, que mezcle los componentes de interfaz y de negocio, cuando se necesite cambiar la interfaz, se deberá realizar un arduo trabajo para poder modificar los componentes de negocio, lo que implica un mayor riesgo de cometer errores. Por lo cual, se realiza un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o los datos.

- Patrón Model-View-Controller: Interacción usuario-computadora. Nos interesa poder mantener múltiples vistas de un mismo modelo, manteniéndolas actualizadas ante cualquier cambio del estado del modelo y poder incorporar nuevos controladores si fuera necesario, sin alterar el comportamiento del modelo.

Controlador

Modelo

Vista

Figura 7.5 - Patrón Broker



Pag 92

- Patrón Layers: Independencia de plataforma. Nos interesa poder descomponer todo lo referente a comunicaciones y a acceso a la base de datos, en grupos o subtareas, en las cuales cada grupo de subtareas tiene un nivel de abstracción particular, de modo que un componente pueda ser reemplazado por implementaciones alternativas sin afectar al resto del sistema.

Capa N-1

Capa 0

Capa N

Figura 7.6 - Patrón Layers

Una vez identificados los patrones a utilizar los integramos de la siguiente manera:

Modelo

Cliente

ControladorVista

Broker

Capa 0

Capa N

Capa N - 1

Layer

Cproxy Sproxy

Servidor

Figura 7.7 - Integración del patrón Broker, Model-View-Controller y Layers

La distribución es preferente, por lo cual, Broker es el primer patrón a aplicar ya que el ambiente es el de un sistema distribuido, y posiblemente heterogéneo, con componentes independientes que cooperan entre sí. Lo que se intenta resolver es el problema de construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan, lo cual conlleva a mayor flexibilidad y facilidad en el mantenimiento y futuros cambios, en lugar de una aplicación monolítica. Al partir la funcionalidad en componentes independientes, el sistema se vuelve potencialmente escalable y distribuido. Por lo tanto:

- Creamos un objeto que actué de broker al sistema remoto.

- Creamos una interfaz para definir el comportamiento remoto del sistema.

- Luego, implementamos un proxy para el cliente y otro proxy para el servidor.

- Los detalles de comunicación quedan dentro del proxy cliente y del proxy servidor.



Pag 93

Para el cliente es transparente la forma de comunicación entre los componentes, respetando la siguiente estructura:

llamarServidor

inicializarTarea

utilizarAPIBroker

Cliente

empaquetarDatos

desempaquetarDatos

llamarServicios

enviarResultados

Proxy del lado

del ServidorcicloPrincipal

registrarServicioencontrarServidor

encontrarCliente

enviarSolicitud

enviarRespuesta

Broker

empaquetarDatos

desempaquetarDatos

enviarSolicitudesregresarResultados

Proxy del lado del Cliente

inicializarseejecutarCicloPrincipal

ejecutarServicio

utilizarAPIBroker

Servidor

transfiere

mensajes

transfiere

mensajes

llama llama

Figura 7.8 - Diagrama de clases del patrón Broker

Si aplicamos a nuestro caso de estudio cada componente del patrón los mismos, estarían ubicados de la siguiente forma en el esquema:

CASA MATRIZ

Server de

la Sucursal

Sistema de Escaneo

de Cheques


Suc 1

Host_Central

CLIENTE (A)

PROXY DEL

LADO DEL

CLIENTE (A)

BROKER

PROXY DEL

LADO DEL

SERVIDOR

SERVIDOR

Servidor Central

SERVIDOR


CLIENTE (B)PROXY DEL

LADO DEL

CLIENTE (B)

Figura 7.9 - Distribución de los componentes del patrón Broker.

Ahora veremos un diagrama de secuencia que representa la interacción entre los componentes del sistema.

En este diagrama se ve el caso en que el usuario realiza la apertura del día:

1. Se inicia la aplicación usuario. Durante la ejecución del programa, el usuario invoca un método de un objeto servidor remoto solicitándole la fecha del día.

2. La aplicación usuario solicita proxy cliente la fecha del día para realizar la apertura.

3. El proxy cliente empaqueta los datos y reenvía la solicitud al broker.

4. El broker localiza el servidor al cual se esta realizando la petición, en este caso al Host Central. Puesto que el servidor esta disponible localmente, el broker envía el mensaje al proxy servidor correspondiente.



Pag 94

5. El proxy servidor desempaqueta todos los parámetros e información relevante, e invoca el servicio apropiado.

6. Después que la ejecución del servicio se completa, el servidor regresa el resultado al proxy servidor, el cual lo empaqueta en un mensaje con información relevante, y lo pasa al broker.

7. El broker envía la respuesta al proxy cliente.

8. El proxy cliente recibe la respuesta, desempaqueta el resultado y lo regresa a la aplicación usuario. Obteniendo de esta manera la fecha del día. El proceso cliente continúa con sus operaciones.

Cliente ServidorProxy del

ServidorBrokerProxy del Cliente

Llamar

servidor

Envia Solicitud

De apertura de dia

Empaquetar

datos

Reexpedir

Solicitud

Encontrar

Servidor

Host Central

Llamar_servicio

Encontrar cliente

Desempaquetar

datos

Ejecutar servicio de

apertura de dia

Enviar fecha del día

Empaquetar

datos

Reexpedir respuesta

Regresar

Desempaquetar

datos

Recibe resultados

Figura 7.10 - Diagrama de secuencia de la interacción entre componentes

A continuación se integra el patrón Model-View-Controller en el patrón Broker.

Si bien existen dos patrones arquitectónicos Model-View-Controller (MVC) y Presentation-Abstraction-Control (PAC) que son aplicables a sistemas interactivos, según la clasificación realizada por [Buschmann+96] y descripta anteriormente en este trabajo, hemos optado por el MVC.



Pag 95

Analizando los patrones, observamos que cada agente PAC consiste de los componentes presentación, abstracción y control manteniendo una analogía parcial con el patrón MVC.

El componente control es similar a lo que seria el componente control en la arquitectura MVC. Este procesa los eventos externos y actualiza los componentes abstracción y presentación. Es diferente del componente control del patrón MVC en que pasa las actualizaciones realizadas a su agente PAC padre.

El componente abstracción contiene los datos al igual que el componente modelo en el patrón MVC. Sin embargo, él puede contener solo parte de la estructura de datos de la aplicación, y no juega un papel activo en la notificación de los cambios.

El componente presentación es exactamente igual que el componente vista en el patrón MVC.

Cabe destacar que estos tres componentes forman cada uno de los agentes PAC, los cuales a su vez forman una estructura jerárquica en forma de árbol de agentes cooperando. Cada agente es responsable de un aspecto especifico de la funcionalidad de la aplicación, provocando que el sistema quede dividido en múltiples componentes presentación, abstracción y control, por lo cual no fue el patrón elegido para el caso de estudio propuesto, además agrega innecesariamente una mayor complejidad en el diseño.

En el diseño de nuestro caso de estudio finalmente se optó utilizar el patrón MVC por las siguientes razones:

- El sistema tiene la funcionalidad central que no está distribuida sino se ubica en un único centro

- La misma información es representada en diferentes vistas de manera distinta (ej: una sucursal tiene una vista detallada de cada uno de los cheques por ella escaneados y el Sistema Centralizador ve sólo la cantidad de cheques escaneados por una sucursal, sin el detalle de cada uno de ellos).

Como se ha visto los elementos de este patrón son:

- Modelo: datos y reglas de negocio.

- Vista: muestra la información del modelo al usuario.

- Controlador: gestiona las entradas del usuario.

Los servidores contienen los diferentes componentes del modelo y los clientes los componentes vista y controlador.

La siguiente figura muestra la conectividad de cada uno de los componentes y las tareas que lleva a cabo cada uno de ellos.



Pag 96

conectar(Observador)

desconectar(Observador)

notificar()

conseguirDatosServicio()

Datos

SeteoDeObservers

Modelo

actualizar()

Observador

inicializar (Modelo)

hacerControlador()activar ()

mostrar()

MiModeloMiControlador

Vista

inicializar (Modelo, Vista)

manejarEventos()

MiModelo

MiVista

Controlador

Llamar

actualizar

crear

conectar

llamada a servicios

Conectar

conserguirDatos

Manipular

display

Figura 7.11 - Diagrama de clases del patrón Model-View-Controller

En la siguiente figura se muestra cada componente del patrón en nuestro caso de estudio:

CASA MATRIZ

Server de

la Sucursal

Sistema de Escaneo

de Cheques


Suc 1

Host_Central

Vista (A) Controlador (A) Modelo

Servidor Central


Vista (B)

Controlador (B)

Figura 7.12 - Distribución de los componentes del patrón Model-View-Controller

Ahora veremos cual es la conducta dinámica de este patrón al realizar la conexión al sistema tras ingresar clave y contraseña.

1. El usuario interactúa con la interfaz de usuario (vista) de alguna forma, como dijimos ingresando la clave y contraseña.

2. El controlador recibe, por parte de los objetos de la vista, la notificación de acción solicitada por el usuario. El controlador gestiona el evento que llega a través de un manejador de eventos.

3. El controlador accede al modelo, actualizándolo con la acción solicitada por el usuario, es decir, interpreta el evento y activa el procedimiento de validación y verificación de clave y contraseña en el modelo.



Pag 97

4. El modelo realiza el servicio requerido. Esto produce un cambio en sus datos internos.

5. El modelo notifica del cambio a todas las vistas y controladores registrados con el mecanismo de propagación de cambios, llamando a sus procedimientos de actualización.

6. Cada controlador registrado recupera los datos del modelo para activar o desactivar ciertas funciones del usuario, como por ejemplo el perfil del usuario que se ha conectado.

7. Cada vista solicita a su controlador los datos modificados del modelo y los refleja en pantalla, por ejemplo mostrando el nombre del usuario que se ha conectado.

8. El controlador original recobra el control y retorna desde su procedimiento manejador de eventos.

9. La interfaz de usuario espera nuevas interacciones del usuario, comenzando con el ciclo nuevamente.

Controlador VistaModelo

servicio

notifica

display

Manejador

de eventos

actualiza

Toma_datos

actualiza

Toma datos

Figura 7.13 - Diagrama de secuencia para la conexión de un usuario al sistema.

Los componentes de los patrones antes mencionados requieren establecer conexiones que les permitan comunicarse teniendo en cuenta que estamos considerando que el caso de estudio es un sistema distribuido.

Esta necesidad de comunicación nos lleva a estructurar dichos componentes en capas mediante la utilización del patrón Layers.

Se tomó la decisión de hacer uso de este patrón debido a que claramente se observa la necesidad de comunicación entre los distintos componentes lo cual nos lleva a pensar que deberíamos independizar la tarea de comunicación de las tareas del



Pag 98

sistema operativo. Separando dos capas independientes, una capa de nivel más bajo que realice las tareas específicas de comunicación y otra capa ubicada sobre la anterior, que realice las tareas propias del Sistema Operativo. En ambos caso hacemos uso de software ya existente.

La integración final de todos los patrones sería:

Modelo

Cliente

ControladorVista

Broker

S.O

Comunicaciones

Layer

Cproxy Sproxy

Servidor

Figura 7.14 - Integración del patrón Broker, Model-View-Controller y Layers.

Capa Sistema Operativo: Es la capa de software que permite gestionar los mecanismos de comunicación, independizar el servicio de su implantación y de los protocolos de comunicaciones, además, permite la convivencia de distintos servicios en un mismo sistema y la transparencia del mismo. El sistema operativo a utilizar en nuestro caso de estudio será alguna de las diferentes plataformas existentes.

Capa de Comunicación: En esta capa se encuentra el protocolo de comunicación, se encarga de transportar los mensajes que intercambian los distintos componentes. El protocolo de comunicaciones que utilizamos es TCP/IP, que a su vez, como ya sabemos, esta estratificado en capas por lo cual es una aplicación más del patrón Layers.

La principal ventaja de la estructuración por capas es que cada capa cumple con funciones y servicios determinados que brinda a la otra capa, esto permite una mejor organización.

También aplicamos el patrón Layers para desarrollar la tarea de acceso a datos en el servidor. Se identifican las capas:



Pag 99

Capa de Acceso a Datos

Capa de Servicio

Procedimiento

Almacenado

Tablas y Vistas

Figura 7.15 - Estructura de Capa de Servicio, Capa de Acceso a Datos y Base de Datos.

En la capa de servicio cada tarea dentro de esta capa se puede encapsular en un método de un componente. Para los procesos más complejos que requieren varios pasos y transacciones de ejecución larga, la aplicación necesita disponer de un modo de organizar las tareas y almacenar el estado hasta que el proceso se haya completado. Además, permite realizar el uso directo por parte de componentes de presentación o su encapsulación como servicio y llamada a través de una interfaz de servicios, que coordina la conversación con los llamadores del servicio.

Capa de acceso a datos, esta capa se encarga de administrar el almacenamiento y obtener el acceso a los datos. Los componentes de acceso a datos exponen métodos para insertar, eliminar, actualizar y recuperar datos. Recibe las solicitudes de la capa de servicio y las convierte en solicitudes a la base de datos específica. Esta capa es fundamental para que los cambios de base de datos no afecten a la aplicación en general.

Puede utilizar un componente de acceso a datos para centralizar la administración de la conexión y todo el código relacionado con un origen de datos.

Se realiza la implementación de las consultas y operaciones de datos como procedimientos almacenados para mejorar el rendimiento y la facilidad de mantenimiento.

El Componente Modelo

Una vez planteado el modelo arquitectónico de nuestro caso de estudio, el próximo paso a seguir es el desarrollo del diseño del componente modelo del patrón Model-View-Controller aplicado anteriormente.

De acuerdo a nuestro análisis previo, el modelo se conforma por tres componentes que interactúan entre sí.

- Deposito de Cheques se encarga de la tarea de realizar y reflejar el depósito de los cheques en sucursales y su posterior envío y del proceso de rechazo de los mismos.



Pag 100

- Recepción de Cheques es el encargado de la recepción y procesamiento de los cheques recibidos, gestión de cobro y rechazo de cheques.

- Reclamos de Cheques efectúa la carga y procesamientos del envío de reclamos, así como también el la recepción y gestión de imágenes a enviar.

Recepción de Cheques

Deposito de Cheques

Solicita imagen

MODELO

Reclamos de Cheques

Solicita imagen

Figura 7.16 - Componentes del Modelo

Las principales entidades que intervienen en cada subcomponente del modelo son:

Sucursal: Representa a una sucursal bancaria, responsable de la apertura y cierre de operaciones, donde se recibe y se envía archivos desde y hacia el Sistema Centralizador.

…

apertura()

generarArchEnvio ()

generarArchImgRech()

generarArchRechazo()

cierre()

...

Sucursal

Banco

Figura 7.17 - Clase Sucursal

Cuenta: Representa una cuenta bancaria de una sucursal de banco. Posee uno o más titulares que son Clientes del Banco, tipo de moneda y tipo de cuenta. Entre otras cosas, es responsable de procesar depósitos y extracciones.

extraer()

depositar()

saldo()

puedoDebitar ()

debitar()

acreditar()

existeCuenta()

numero

Cuenta

TipoMoneda

Cliente

TipoCuenta

…

apertura()

generarArchEnvio ()



cierre()

...

Sucursal

Figura 7.18 - Clase Cuenta



Pag 101

Cheque: Representa a un cheque de una cuenta bancaria, tiene un importe y una fecha. Es responsable de saber si puede debitarse en la cuenta a la que pertenece y de hacerlo si se lo solicita.

importe()

fechaEmision()

puedeDebitar ()

debitar()

numero

Cheque

extraer()

depositar()

saldo()

puedoDebitar ()

debitar()

acreditar()

existeCuenta()

numero

Cuenta

miCuenta

Figura 7.19 - Clase Cheque

Cuando un cheque es depositado en una cuenta, puede ser que corresponda a la misma sucursal o no. Este segundo caso es el que nos interesa en particular, ya que estos cheques tienen un tratamiento especial, su cobro debe ser gestionado en otro banco. Además de la información propia del cheque, conoce la cuenta en la que se depositó, y es responsable de generar el registro con su información para enviar al sistema centralizador, procesar el depósito o el rechazo según lo que ocurra.

Para modelar el cheque depositado en otra sucursal, podríamos pensar en subclasificar a Cheque e incorporar el nuevo comportamiento. Si Cheque tuviera ya otras subclasificaciones como por ejemplo Cheque Diferido, cada una de estas subclases debiera admitir la posibilidad de depositarse en otra sucursal. Por otro lado, el cheque existe como entidad, y se requiere que dinámicamente sea considerado como cheque depositado. Por ello, la subclasificación no es la forma más adecuada de representarlo, siendo la composición la mejor manera.

extraer()

depositar()

saldo()

puedoDebitar ()

debitar ()

acreditar()

existeCuenta()

numero

Cuenta

…

generarRegistro()

procesarRechazo()

asociarImagen()

…

ChequeOtraSucursal

miCuenta

miChequeimporte()

fechaEmision()

puedeDebitar ()

debitar()

numero

Cheque

cuentaDeposito

Figura 7.20 - Clase ChequeOtraSucursal.

Para generalizar más este esquema y dar la posibilidad a que un cliente pueda trabajar indistintamente con un Cheque o con un Cheque Depositado, aplicamos el patrón Decorator.



Pag 102

acreditar()

importe()

fechaEmision()

puedeDebitar ()

debitar()

numero

ChequeDepositado

…..

numero

Cuenta

…..

numero

Cuenta

cuentaDeposito

importe()

fechaEmision()

puedeDebitar ()

debitar ()

numero

Cheque

…

generarRegistro()

procesarRechazo()

asociarImagen()

…

ChequeOtraSucursal

miCuenta

numero

ChequeNormal

importe()

m̂iCheque.importe()

Figura 7.21 - Aplicación Patrón Decorator

Consideramos la clase cheque como una interfaz permitiendo de esta manera un tratamiento indistinto tanto a los cheques normales como a los cheques depositados. Considerando a cheques normales aquellos cheques que son presentados en caja para su cobro, pero no son depositados en una cuenta. Caso contrario será un cheque depositado, que a su vez puede ser un cheque propio (cuya cuenta origen pertenece a la sucursal del deposito) o un cheque de otro banco u otra sucursal. La separación de estas clases se debe a que cada una de ellas tiene un comportamiento particular.

En nuestro caso solo nos centraremos en el comportamiento de los cheques depositados. Si bien aplicamos el patrón Decorator, en los diagramas subsiguientes utilizamos la interfaz cheque sin representar sus subclases para dar mayor simplicidad al esquema del modelo.

Depósito de Cheques

Aquí se modelizan los procedimientos del depósito de un cheque, desde su registración por caja y digitalización hasta el procesamiento y generación de archivo para su posterior envío al Sistema Centralizador al efectuar el cierre de operaciones en la sucursal. Así como también la apertura y recepción de los rechazos correspondientes a cheques depositados y enviados el día anterior.

Al efectuar el depósito de un cheque por caja, se cargan todos los datos referentes a la boleta y al cheque. El depósito se realiza en la cuenta del cliente depositante, el cual debe contar con los siguientes datos: tipo de cuenta (cuenta corriente, caja de ahorros, etc.), tipo de moneda (pesos, dólares, euros, etc.), sucursal y número. Todos



Pag 103

estos datos en su conjunto son necesarios para indicar la existencia y validez de la cuenta. Otro dato requerido es la fecha del depósito.

En caso de que el cheque corresponda a una cuenta de la sucursal donde se realiza el depósito, el mismo será debitado de su cuenta origen en si el saldo es suficiente y será acreditado en la cuenta del cliente depositante. Por lo tanto el cheque adopta el estado aceptado. Caso contrario, es decir, si corresponde a un cheque de otra sucursal o de otro banco, pasamos a la fase de digitalización, quedando el cheque en estado depositado.

Cada cheque tiene en su parte inferior un código de barras que, al ser digitalizado, permite la captura automática del banco, sucursal, código postal, número de cheque y número cuenta al que pertenece el cheque, restando sólo la tarea de completar en forma manual su importe, quedando de esta forma generado el registro electrónico del cheque con su imagen digitalizada.

Al finalizar el día, la sucursal realiza el cierre de operaciones, este proceso toma todos los cheque que se encuentran en estado depositado y genera un archivo para su envío, esto provoca que los cheques cambien al estado enEspera.

El archivo generado es transferido al Sistema Centralizador, quien una vez recibidos los archivos de todas las sucursales los procesa conformando un único archivo para enviar a la Cámara Compensadora.

Al día siguiente, al realizar la apertura de operaciones en la sucursal, se reciben los rechazos de los cheques depositados el día anterior. En este procedimiento se contrastan los cheques enviados con los rechazos recibidos.

Si no se recibe rechazo de un cheque, el mismo cambia su estado a aceptado y es acreditado en la cuenta depositaria asociada.

Si se recibe rechazo de un cheque, se procesa el rechazo del mismo, esto implica la realización de un movimiento de debito y crédito en la cuenta depositaria asociada, provocando que el cheque cambie su estado a rechazado. Este proceso también involucra el análisis del código de rechazo recibido. Si este código implica generar imagen se busca la imagen del cheque y se conforma un registro con la imagen.

Con la realización del cierre de operaciones en la sucursal, se genera un archivo con las imágenes a enviar y este archivo es transferido al Sistema Centralizador.



Pag 104

extraer()

depositar()

saldo()

puedoDebitar()

debitar ()

acreditar()

existeCuenta()

numero

Cuenta

TipoMoneda

Cliente

…

apertura()

cierre()

generarArchEnvio()


...

numero

Sucursal

TipoCuenta

Deposito de Cheques

…

generarRegistro()

procesar()

asociarImagen()

…

ChequeOtraSucursal

Banco

Estado

Imagen

Estado Fecha

RechazadoEnEsperaDepositado

chequeOtraSucursal

miCuenta

cuentaDeposito

miChequeestado

Aceptado

RecepcionProcesamientoChequesRechazados()

Por cada cheque rechazado

Buscar Registro electrónico en ChequeOtraSucursal

Si lo encuentra

ChequeOtraSucursal.procesarRechazo()

sino

excepcion cheque no encontrado

finsi

CodigoRechazo

importe()

fechaEmision()

puedeDebitar()

debitar ()

numero

Cheque

sucursal:: apertura()

RecepcionProcesamientoChequesRechazados()

RecepcionProcesamientoChequesPresentados()

RecepcionProcesamientoChequesReclamados()

Figura 7.22 - Depósito de Cheques

Recepción de Cheques

El componente Recepción de Cheques es el encargado de la recepción y procesamiento de los cheques recibidos, su imputación monetaria y generación de rechazos.

Al momento de la apertura de operaciones de la sucursal, se reciben los cheques que han sido escaneados en otros bancos para gestionar su cobro.

Todos los cheques recibidos se encuentran en estado recibido y luego comienza el procesamiento para generar su imputación monetaria en las cuentas. Si el cheque puede debitares, entonces se debita su importe del saldo de la cuenta, tomando en este momento el estado aceptado. En caso de no poder debitarse se marca el cheque con un código de rechazo y se genera el registro adoptando el cheque el estado rechazadoConCodigo o rechazado dependiendo si se requiere la imagen o no.

En caso de ser rechazado con el requerimiento de imagen, se mantiene en estado rechazadoConCodigo hasta que se reciba la imagen correspondiente, pasando luego definitivamente a estado rechazado.

Al realizar el cierre de operaciones de la sucursal se tomaran todos los cheques rechazados y se generara un archivo que será enviado al Sistema Centralizador para su gestión.



Pag 105

extraer()

depositar()

saldo()

puedoDebitar ()

debitar()

acreditar()

existeCuenta()

numero

Cuenta

TipoMoneda

Cliente

...

apertura()


cierre()

...

numero

Sucursal

TipoCuenta

Recepción Cheques

…

generarRechazo()

procesarRegistro()

asociarImagen()

…

ChequeOtraSucursal

Banco

Estado Imagen

Estado Fecha

AceptadoRechazadoRechazadoConCodigoRecibido

chequeOtraSucursal

miCuentacuentaDeposito

miChequeestado

importe()

fechaEmision()

puedeDebitar ()

debitar()

numero

Cheque

CodigoRechazoCheque:: debitar ()

miCuenta.debitar (this.importe())

Sucursal:: apertura()

RecepcionProcesamientoChequesPresentados ()

Por cada cheque presentado a debitar

Si cheque.puedeDebitarse() ent

cheque.debitar ()

sino

generarRechazo (cheque)

finsi

fin

Figura 7.23 - Recepción de Cheques

Para los casos de la representación y comportamiento de los cheques a través de su estado podríamos hacer uso del patrón State, cuyo propósito permite cambiar fácilmente el comportamiento de un objeto en tiempo de ejecución. Los objetos son estados, que se mantienen a través de los atributos y el comportamiento que se define en los métodos. El comportamiento dinámico del objeto se alcanza delegando todas las llamadas a métodos que confían en ciertos valores para un objeto que representa el estado y al modificar esos objetos también se obtiene un comportamiento diferente.

Una alternativa en lugar de la aplicación del patrón State es la utilización de una sentencia de selección múltiple como switch para decidir que tareas se realizan de acuerdo al valor del estado que adopta el cheque. Al utilizar el patrón State ponemos todo el comportamiento asociado a un estado en un objeto, evitando el uso de switch monolíticos para los diversos casos así como también la replicación de código, permitiendo la incorporación de nuevos estados sin afectar lo ya desarrollado.

En nuestro caso de estudio vemos que el objeto ChequeOtraSucursal cambia su comportamiento de acuerdo al estado en que se encuentra.

Un cheque que ha sido depositado por caja y digitalizado, permanecerá en estado depositado, hasta que el cierre de operaciones en la sucursal genere el archivo de envío provocando el cambio de estado de los cheques a enEspera.

Una vez recepcionado el archivo de rechazos el cheque adoptará el estado aceptado o rechazado según tenga un código de rechazo asociado o no.



Pag 106

El comportamiento del cheque en la Recepción de Cheques, también tendrá cambios de estados.

Al ser recibido, se encuentra en estado recibido, que luego de ser imputado cambiará a estado aceptado, rechazado o rechazadoConCodigo dependiendo de la situación.

Un esquema de aplicación del patrón State para representar los cambios de estados de los cheques se muestra a continuación.

…

setEstado()

procesarRegistro()

…

ChequeOtraSucursal

procesar()

Estado

procesar()

Aceptado

procesar()

Rechazado

procesar()

RechazadoConCodigo

procesar()

Recibido

Fecha

CodigoRechazo

Figura 7.24 - Aplicación del Patrón State en el Componente Recepción de Cheques

Reclamos de Cheques

El componente Reclamo de Cheques es el encargado de la recepción y procesamiento de cheques reclamados tanto enviados como recibidos.

Al inicio del día, la sucursal recibe los reclamos que se han efectuado por otros bancos para su procesamiento así como también las imágenes reclamadas que se han recibido por reclamos efectuados a otros bancos.

Reclamos Recibidos

Por cada reclamo recibido se busca el cheque correspondiente a ese reclamo. Si corresponde a un cheque digitalizado en esta sucursal se ubica su imagen y se asocia al registro electrónico. Si no corresponde, se genera el rechazo del reclamo. En ambos casos al realizar el cierre de operaciones se envían los archivos al Sistema Centralizador para su gestión.

Reclamos Enviados

Cuando la sucursal hace un reclamo, como ya dijimos este corresponde a un cheque anteriormente recibido. La sucursal genera un registro con los reclamos a realizar y al cierre del día se envían al Sistema Centralizador.

Cuando el banco destinatario del reclamo cumple con la imagen y esta es recibida en la sucursal se debe asociar al registro electrónico del cheque recibido, finalizando de esta manera con el circuito de reclamos.



Pag 107

Una forma de representar este componente seria agregando un nuevo estado al cheque, es decir estado reclamado, y en base a este nuevo estado se realizaran los procesamientos antes indicados ante la presencia de un reclamo enviado o un reclamo recibido.

Los Componentes Vista y Controlador

Tanto la vista como el controlador dependen del componente modelo lo cual no sucede en forma inversa, como ya se ha mencionado. Esta separación permite construir y probar el componente modelo independientemente de la representación visual. El modelo tiene diversas vistas, cada una con su correspondiente controlador.

La vista maneja la visualización de la información del modelo al usuario.

En nuestro caso de estudio contaremos con vistas ubicadas en cada una de las sucursales y otras en el Sistema Centralizador.

La vista en una sucursal determinada sólo muestra la información referente a cheques recibidos, enviados, rechazados y reclamados correspondientes a esa sucursal específicamente.

La vista en el Sistema Centralizador muestra la información referente a cheques recibidos, enviados, rechazados y reclamados de todas las sucursales.

Mientras la vista en las sucursales muestra información con un alto nivel de detalle (cheque por cheque), la vista en el Sistema Centralizador sólo muestra un resumen de las transacciones realizadas por sucursal. También se muestra el estado en que se encuentra cada una de las sucursales (por ejemplo estado apertura del día, estado consultando, estado escaneando, etc.)

El controlador interpreta las acciones del usuario informando al modelo y a la vista para que cambien según resulte apropiado.

Existe un controlador por cada vista, el cual permite relacionar la solicitud de servicio realizada en la vista asociándola al evento que detecta el controlador.

Un ejemplo dentro de nuestro caso de estudio es cuando se deposita un cheque y se cargan todos los datos de la cuenta, el evento de pulsar la tecla enter activará a través del controlador una petición de servicio al modelo que será una llamada al método existeCuenta(). El modelo ejecuta el método y notifica del resultado de la verificación a la vista y controlador registrados con el mecanismo de propagación de cambios. Una vez finalizada esta notificación vuelve a tomar el control el controlador.

El mecanismo de propagación de cambios realizado aquí se lleva a cabo a través de la implementación del patrón de diseño Observer. Este patrón como ya mencionamos nos permite definir una dependencia de uno a muchos entre un objeto de datos y n objetos (observers) que representan estos datos, de manera que si desde uno de los observers se cambian los datos, el objeto de datos notifica este cambio a todos los observers restantes.



Pag 108

Un componente de este patrón cumple el rol de subject, quien contiene métodos mediante los cuales cualquier observer o vista se puede suscribir a él referenciándose a así mismo. El subject mantiene una lista de sus observers.

Los observers deben implementar métodos determinados mediante los cuales el subject es capaz de notificar a sus observers "suscriptos" los cambios que sufre para que todos ellos puedan refrescar el contenido representado.

Asociando los componentes del patrón de diseño Observer con los componentes del patrón arquitectónico Model-View-Controller, determinamos que el componente modelo es quien cumple el papel del subject y los componentes vista y controlador actúan como observers.

Un ejemplo de aplicabilidad del patrón Observer es cuando se reciben los archivos de imágenes por reclamo o por rechazo y se notifica a las sucursales la recepción de las mismas informando que están a disposición para su toma y procesamiento.

estadoObserver= subject->obtenerEstado();obtenerEstado()

definirEstado()

estado

ConcreteSubject

avisar()

estadoObserver

ConcreteObserver

observer do: {

:each|each avisar]

añadir(Observer)

eliminar(Observer)

notificar()

Subject

avisar()

Observer

return estado;

Figura 7.25 - Patrón Observer



Pag 109

Caso Arquitectura.pdf

Documents

Transcript of Caso Arquitectura.pdf