Caso Arquitectura

Captulo 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 implementacin de un nuevo sistema en la gestin de
cobro de Cheques.
Este sistema permite la captura descentralizada de cheques de cualquier importe,
eliminndose en todo el pas el traslado fsico de los mismos, quedando estos en poder
de las Entidades Depositarias independientemente de su lugar de captacin 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
generacin de los registros electrnicos y sus respectivas imgenes (digitalizacin).
Transmitindose los registros electrnicos y las imgenes de los cheques superiores a
un importe determinado.
Participantes
Los distintos participantes en el sistema son los que a continuacin se detallan:
Participantes Internos al sistema:
- Las Sucursales de la Entidad Depositaria: Son quienes efectan la digitalizacin y
carga de todos los datos correspondientes al cheque depositado por el cliente en
caja.
- Entidad Girada: Es quien recibe la informacin electrnica de los cheques, y previa
verificacin de la misma, debita el importe a sus clientes libradores y abona a la
Entidad Depositaria.
Participantes Externos al sistema
- Cmara Compensadora: Es la administradora de la compensacin electrnica de
medios de pagos y sus funciones se detallan a continuacin:
!
Refundicin de los archivos recibidos de las Entidades Depositarias y

clasificacin de stos por Entidad Girada, generando los archivos con el
detalle de transacciones para su posterior envo
Refundicin de los archivos de rechazos recibidos de las Entidades

Giradas y la clasificacin de stos por Entidad Depositaria, generando los
archivos conteniendo el detalle de las operaciones para su posterior
envo.
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 2
Suc 2
Suc 3
Suc 3
Suc 4
Suc 4
Suc 1
Suc 1
Entidad Depositaria /
Girada
Entidad Depositaria /
Girada
Camara
Compensadora
Figura 6.1 - Esquema a gran escala
Esquema solucin dentro de cada Entidad:

Entidad Depositaria / Girada
Suc 1
CASA MATRIZ
Sistema de Escaneo
de Cheques
Server de la Sucursal
Sistema de Escaneo
de Cheques
Suc 2
Sistema Centralizador
Host_Central
Sistema de Escaneo
de Cheques
Suc 3
Sistema de Escaneo
de Cheques
Servidor Central
Cmara
Compensadora
Suc 4
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
Definicin del Sistema

Podemos especificar tres grandes circuitos que consisten en el envo/recepcin diario
de archivos a la Cmara Compensadora donde se encuadran cada una de las sesiones,
denominando sesin al proceso de envo o recepcin de archivos desde/hacia la
Cmara Compensadora, correspondiente a cada tem de cada uno de los circuitos.
Circuito de Cheques
Las Entidades transmitirn a la Cmara Compensadora archivos conteniendo los
registros electrnicos correspondiente a los cheques que dicha Entidad presenta para
su compensacin electrnica en sesiones diariamente. Se entiende por registro
electrnico al conjunto de datos que definen a un cheque - banco, sucursal, cdigo
postal, nmero de cheque, nmero 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
electrnicos e imgenes), donde se gestionan los distintos archivos para su posterior
envo.
Respecto al envo de archivos se identifican tres sesiones.
- Cheques: Corresponde a la generacin de un archivo conteniendo los registros
electrnicos de los cheques.
- Imgenes: Se genera un archivo conteniendo todas la imgenes correspondientes a
los cheques escaneados en el da, que superen un importe determinado.
- Rechazos de Cheques: Luego de imputar los cheques recibidos, capturados en otros
bancos el da 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 Tcnica, etc.).
En el circuito de cheques recibidos, los archivos estn conformados por cheques
que han sido capturados en otros bancos el da anterior y son recibidos para su
imputacin en sus respectivas cuentas.
Respecto a la recepcin de archivos se identifican tres sesiones.
- Cheques Recibidos: Se recepciona y procesa un archivo conteniendo los registros
electrnicos de cheques procedentes de otros bancos para su cobro.
- Imgenes: Se recepciona y procesa un archivo con todas las imgenes de los
cheques que han sido capturados en otros bancos.
- Rechazos de Cheques: Se recepciona y procesa un archivo con los registros
electrnicos de los cheques rechazados por la Entidad Girada. Estos rechazos
corresponden a cheques enviados por la Entidad Depositaria anteriormente.

Pag 81
Entidad Girada
Presentacin de Cheques
Recepcin de Rechazos
Recepcin de Cheques
Rechazo de Cheques
Presentacin de Imgenes
Recepcin de Imagenes
Entidad
Depositaria
Camara
Compensadora
Figura 6.3 - Esquema dentro de cada una de las entidades.
Circuito de Imgenes por Rechazo

Luego del proceso de recepcin de los cheques y su imputacin contable, se genera el
archivo de Cheques rechazados. Para indicar el rechazo de un cheque, se asocia a su
registro electrnico un cdigo de rechazo. Dependiendo del cdigo de rechazo, la
Entidad Depositaria deber enviar, o no, a la Entidad Girada la imagen del mismo.
El envo de los archivos se realiza por diferentes sesiones:
- Imgenes por rechazo: Una vez recibidos los archivos de rechazos se deber enviar
a la Entidad Girada las imgenes de aquellos cheques que segn su cdigo de
rechazo lo requieran.
- Rechazo de Imgenes por rechazo: En caso de recibir imgenes de una Entidad
Depositaria que no correspondan a los cheques rechazados oportunamente, se
deber generar un archivo indicando el rechazo de la imagen.
La recepcin de los archivos se realiza por diferentes sesiones:
- Imgenes por Rechazo: Una vez enviados los archivos de rechazos a la Entidad
Depositaria, se deber recibir de la misma, un archivo conteniendo las imgenes
correspondientes a los cheques rechazados por los cdigos que generan envo de
imagen.
- Rechazo de Imgenes por rechazo: En esta sesin se recibirn rechazos de aquellas
imgenes que se enviaron por rechazo y no se corresponden con los datos del
registro electrnico del cheque rechazado.
Entidad Girada
Presentacin de Rechazos
Rechazo de Imagenes
Rechazo de Rechazo
Recepcin de Rechazo de
Imgenes
Entidad
Depositaria
Camara
Compensadora
Figura 6.4 - Circuito de Imgenes por rechazo

Pag 82
Circuito de Imgenes por Reclamos

El circuito de intercambio de imgenes por reclamo de cheques, es similar al que se
usa en el circuito de imgenes de cheques rechazados.
Los reclamos se efectan sobre cheques recibidos que, al gestionar su cobro no se
contaba con la imagen. Esta operacin es solicitada por el cliente librador del cheque.
Mediante diferentes sesiones se gestiona el envo de los archivos:
- Reclamos de cheques: Se genera un archivo conteniendo todos los registros
electrnicos correspondientes a reclamos efectuados en sucursales.
- Imgenes por reclamo: Se genera un
correspondientes a los reclamos recibidos.
archivo
con
todas
las
imgenes
- Rechazo de Imgenes por reclamo: en caso de recibir imgenes de la Entidad

Depositaria que no corresponden a los cheques reclamados, se genera un archivo
indicando el rechazo de la imagen.
La recepcin de los archivos se realiza por diferentes sesiones:
- Cheques reclamados: Se procesa el archivo conteniendo los registros electrnicos
que indican las imgenes reclamadas que se deben enviar.
- Imgenes por reclamo: Se procesa el archivo que contiene las imgenes
correspondientes a los cheques reclamados.
- Rechazo de Imgenes por reclamo: Se procesa el archivo que indica que se han
enviado imgenes que no se correspondan con los reclamos recibidos.
Entidad Girada
Presentacin de Reclamos
Rechazo de Imagenes
Recepcin de Reclamos
Rechazo de Reclamos
Recepcin de Rechazo de
Imgenes
Entidad
Depositaria
Camara
Compensadora
Figura 6.5 - Circuito de Imgenes por reclamo
Limites del sistema

El caso de estudio se limita a realizar el anlisis y diseo arquitectnico del sistema
correspondiente a la captura descentralizada de los cheques en sucursales de las
Entidades Depositarias y la recepcin/envo de la informacin desde/al Host Central en
Casa Matriz, el cual ser el responsable de gestionar la comunicacin con la Cmara
Compensadora a travs del Servidor Central.

Pag 83
Visin Arquitectnica
Realizando un diagnstico 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 geogrficamente separadas y con diferentes
tecnologas de comunicacin.
- El ncleo de la funcionalidad se encuentra en un Servidor Central ubicado en Casa
Matriz.
- Las sucursales acceden a esta funcionalidad por medio de PCs.
Interactivo:
- Aplicacin instalada en sucursales.
- Variedad de tipos de interfaz de usuario.
- Formularios, mens, cajas de dilogos, para interaccin basada en eventos.
Independencia de plataformas
- Distintos servidores de base de datos, clientes con diferentes sistemas operativos.
Para realizar la definicin de la arquitectura de base que capture toda la estructura de
los subsistemas fundamentales de la aplicacin, como primer paso, debemos definir la
infraestructura identificando las propiedades de todo el sistema global, Distribuido e
Interactivo, es decir:
- Seleccionar los patrones arquitectnicos adecuados.
- Combinar los patrones arquitectnicos seleccionados.
- Identificar los subsistemas funcionales: Utilizar los mtodos de anlisis y diseo
convencional.
- Integrar los subsistemas funcionales con la infraestructura del sistema

Pag 84
Captulo 7
Aplicacin de Patrones
En este captulo nos proponemos identificar patrones arquitectnicos y definir
microarquitecturas y modelos de diseo basados en objetos, que permitan modelar el
sistema anteriormente descripto de modo que resulte una aplicacin extensible, fcil
de modificar, mantener y reusar.
Se presenta el anlisis y diseo realizado para nuestro trabajo, describiendo
especialmente los patrones utilizados y las razones de su seleccin.
Anlisis
En la presente seccin se describir el anlisis del sistema. Esta etapa comienza con el
estudio del proceso de gestin de cobro de cheques en el sistema bancario.
Como se mencionara en el captulo anterior, este sistema permite la captura
descentralizada de cheques de cualquier importe, eliminndose en todo el pas el
traslado fsico de los mismos, quedando estos en poder de las Entidades Depositarias
independientemente de su lugar de captacin 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
transaccin y efecta el envo de la informacin electrnica a la Cmara
Compensadora, quien separa y distribuye los archivos a las Entidades Giradas, las
cuales, recibirn los archivos y se encargaran de impactar los movimientos de los
cheques en las cuentas libradoras
A continuacin se ver con ms 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
relacin 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
imgenes por rechazo.

Pag 85
Entidad Depositaria
Entidad Girada
Deposito por Caja
Registracin del
Cheque
Si
Si es Cheque
propio
No
Pago o Rechazo segn

saldo suficiente
Escaneo de cheques
Generacin y envo de archivo de

cheques escaneados
Recepcin y procesamiento de
archivo de cheques escaneados
Imputacin de cheques
(Debito)
Imputacin de cheques (Crdito)
Cheque
rechazado?
No
Si
Recepcin de cheques
rechazados
Generacin de cheques
rechazados
Imputacin de cheques (Crdito y

Debito)
No
Cdigo de
rechazo genera
imagen?
Si
Bsqueda de la imagen
correspondiente al cheque rechazado
Generacin de archivo con

imgenes por rechazo
Recepcin y procesamiento de
Imgenes por rechazo
Corresponde
imagen?
Si
Chequear imagen en
Sucursal
No
No
Imagen vlida
para sucursal?
Marcar rechazo de
reclamo
Si
Aceptacin de
imagen
SI
Procesar rechazo de imgenes

por rechazo
Generar rechazo de imgenes

por rechazo
Figura 7.1 - Circuito de Depsito de Cheques
El proceso comienza con el depsito 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 digitalizacin de todos los
cheques as como la integracin de sus datos. Una vez concluida esta tarea, en forma
Pag 86
centralizada se genera
Girada. Una vez aqu,
monetaria, efectuando
consecuencia de este
rechazado o aceptado:
el archivo conteniendo todos los cheques a enviar a la Entidad

se recepciona, se procesa el archivo y se realiza su imputacin
los dbitos en las cuentas corrientes correspondientes. Como
proceso, se plantean dos situaciones, el cheque puede ser
- Aceptado: en este caso, la Entidad Depositaria al da siguiente al no recibir rechazo,

procede a la acreditacin del importe del cheque en la cuenta depositaria
correspondiente. Concluyendo de esta manera con el circuito de digitalizacin de
cheques.
- Rechazado: La Entidad Girada genera un archivo conteniendo todos los cheques
que desea informar como rechazados, con sus respectivos cdigos de rechazo, y lo
enva 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 dbito
y un movimiento de crdito, mostrando de esta manera el ingreso de los cheques al
circuito y su posterior rechazo.
La tarea posterior a la imputacin monetaria de los cheques rechazados es analizar su
cdigo de rechazo asociado. En caso de:
- Cdigo de rechazo que no genera imagen: Concluye el circuito de cheques
rechazados.
- Cdigo de rechazo que si genera imagen: Se buscan las imgenes correspondientes
a los cheques que se han rechazado, se genera un archivo y se enva a la Entidad
Girada.
La Entidad Girada cuando recibe el archivo con imgenes por rechazo debe arbitrar los
medios para efectuar la recepcin y procesamiento del mismo, donde debe chequear si
corresponden a imgenes de cheques rechazados:
- Si corresponden a cheques rechazados se enva a la sucursal para su chequeo
visual.
- Si no corresponden a cheques rechazados, se genera en forma automtica el
rechazo de la imagen.
Una vez que las imgenes se encuentran en la sucursal, se realiza el chequeo visual de
las mismas.
- En caso de poder contar con la imagen sin problemas de visualizacin se acepta la
imagen dando por concluido el circuito de rechazos.
- En caso de tener algn problema de visualizacin, 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 automtica o porque una
sucursal la marc, se genera el archivo de rechazo de imgenes 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 imgenes por rechazo.
Como vemos en este ltimo caso, nos encontramos en la situacin en que la Entidad
Girada an no cuenta con las imgenes de los cheques que ha rechazado. Como
consecuencia de ellos existe a disposicin de esta entidad la posibilidad de efectuar
reclamos sobre los cheques que ha recibido.
En la siguiente figura 7.2 se muestra dicho circuito.
Entidad Depositaria
Entidad Girada
Realizar reclamo en
sucursal
Recepcin y procesamiento de archivo

de reclamos
Generar archivo de reclamo
Verificacin de reclamos
Si
No
Cheque enviado ?
Buscar imagen correspondiente al

cheque reclamado
Generar rechazo de reclamo

Recibir rechazo de reclamos
Recibir archivo con imgenes

por cheques reclamados
Generar archivo con imagen
No
Corresponde la
imagen ?
Si
Controlar imagen en
sucursal
Imagen vlida para

sucursal?
Si
No
Marcar rechazo
Generar rechazo de imgenes

por reclamo
Procesar rechazo de imgenes
por reclamo
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
imgenes de aquellos cheques cuyo importe sea inferior al importe predefinido para el
envo de imgenes 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 envan 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 automtica
el reclamo con un nuevo cdigo de rechazo, se genera un archivo conteniendo los
rechazos de imgenes por reclamo y se enva 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 imgenes y se enva a la otra entidad.
La Entidad Girada cuando recibe el archivo con imgenes por reclamo efecta la
recepcin y procesamiento del mismo, donde chequea si corresponde a los reclamos
efectuados:
- Si corresponden a cheques reclamados se enva a la sucursal para su verificacin
visual.
- Si no corresponden a cheques reclamados, se genera en forma automtica el
rechazo de la imagen.
Una vez en la sucursal, se realiza la verificacin 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 automtica o porque una
sucursal la marc, se genera el archivo de rechazo de imgenes por reclamo, el que es
enviado a la Entidad Depositaria.
La Entidad Depositaria recibe y procesa dichos rechazos, concluyendo con el circuito de
imgenes por reclamo.
Modelo de casos de uso

Con la informacin 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 informacin de
todas las sucursales.
Para que un usuario pueda acceder al sistema deber identificarse previamente, una
vez autenticado podr tener acceso a la informacin (registro electrnico y/o imagen)
e ingresar nuevos cheques.
Con estas funcionalidades definidas, el sistema estar compuesto por los siguientes
grupos de casos de uso:
Validacin:
- Validar el ingreso correcto de un actor al sistema a travs de su nombre de usuario
y su password y obtener la fecha en forma centralizada.
- Verificacin y validacin de nmeros de cuentas depositarias en el momento del
depsito del cheque.
- Verificacin si corresponde a un cheque propio o un cheque de otra sucursal u otro
banco.
Apertura y cierre de operaciones:
- Realizar la apertura del da en la Sucursal: Se reciben archivos del sistema
centralizador:
!
Cheques Presentados
Cheques rechazados recibidos
Reclamos recibidos
- Realizar el cierre del da provocando la generacin y envo de los archivos

correspondientes a
!
Cheques depositados
Reclamos enviados
Rechazos enviados
Bsqueda de informacin: (Utilizado por el usuario)

- Desplegar la informacin existente en la base de datos. Permitir ver slo los
registros electrnicos/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 visualizacin de su imagen.
- Cheques Enviados con visualizacin de su imagen.
- Consultar la historia de un cheque (recibido, enviado, aceptado, rechazado, envo
de imgenes por reclamo/rechazo, recepcin de imgenes por reclamo/rechazo).

Pag 90
Depsito de cheques: (Utilizado por el usuario):

- Depsito y digitalizacin de cheques: Esta tarea se realiza en el momento que el
cliente se presenta por caja y efecta el depsito 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 automtica los datos de los cheques
(banco, sucursal, cdigo postal, nmero de cheque y nmero de cuenta) por lo que
resta la integracin manual por parte del usuario del nmero de cuenta depositaria
e importe del cheque depositado. En este proceso la imagen capturada del cheque
se asocia al registro electrnico del mismo definiendo en l, path y nombre del
archivo fsico de la imagen.
Administracin de datos: tener a disposicin ABM que permitan
- ABM de Reclamos
- Generar Rechazos de Imgenes recibidas por Reclamos
- Generar Rechazos de Imgenes recibidas por Rechazos
Sistema de Escaneo
de Cheques
Validacin
Apertura y cierre
de operaciones
Bsqueda
de Informacin
Usuario
Depsito de
Cheques
Sistema
Centralizador
Administracin
de datos
Figura 7.3 - Diagrama de casos de uso

Pag 91
Diseo
El Modelo Arquitectnico
El objetivo principal del diseo arquitectnico es representar componentes que
interacten entre ellos y tener asignadas tareas especficas, 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
arquitectnicos:
- Patrn Broker: Soporta la distribucin y la integracin de componentes. Nos interesa
que la aplicacin que usa un objeto lo haga a travs de la interfaz ofrecida por ese
objeto, despreocupndose de los detalles de su implementacin o su ubicacin fsica
y que las invocaciones de servicios remotos sean transparentes respecto de su
ubicacin.
Cproxy
Broker
Sproxy
Cliente
Servidor
Figura 7.4 - Patrn Broker
Para el diseo de aplicaciones con interfaces grficas se utiliza el patrn Model-ViewController. La lgica de una interfaz de usuario cambia con ms frecuencia que los
almacenamientos de datos y la lgica de negocio. Si se realiza un gran diseo, 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
diseo 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 lgica
de negocio o los datos.
- Patrn Model-View-Controller: Interaccin usuario-computadora. Nos interesa poder
mantener mltiples vistas de un mismo modelo, mantenindolas actualizadas ante
cualquier cambio del estado del modelo y poder incorporar nuevos controladores si
fuera necesario, sin alterar el comportamiento del modelo.
Vista
Modelo
Controlador
Figura 7.5 - Patrn Broker

Pag 92
- Patrn Layers: Independencia de plataforma.

lo referente a comunicaciones y a acceso a la
en las cuales cada grupo de subtareas tiene
modo que un componente pueda ser
alternativas sin afectar al resto del sistema.
Nos interesa poder descomponer todo

base de datos, en grupos o subtareas,
un nivel de abstraccin particular, de
reemplazado por implementaciones
Capa N
Capa N-1
Capa 0
Figura 7.6 - Patrn Layers
Una vez identificados los patrones a utilizar los integramos de la siguiente manera:
Broker
Layer
Capa N
Cproxy
Sproxy
Capa N - 1
Cliente
Vista
Controlador
Servidor
Capa 0
Modelo
Figura 7.7 - Integracin del patrn Broker, Model-View-Controller y Layers
La distribucin es preferente, por lo cual, Broker es el primer patrn a aplicar ya que el

ambiente es el de un sistema distribuido, y posiblemente heterogneo, 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 aplicacin monoltica.
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 comunicacin quedan dentro del proxy cliente y del proxy servidor.

Pag 93
Para el cliente es transparente la forma de comunicacin entre los componentes,

respetando la siguiente estructura:
Proxy del lado
del Cliente
empaquetarDatos
desempaquetarDatos
enviarSolicitudes
regresarResultados
transfiere
mensajes
transfiere
mensajes
Broker
cicloPrincipal
registrarServicio
encontrarServidor
encontrarCliente
enviarSolicitud
enviarRespuesta
Proxy del lado

del Servidor
empaquetarDatos
desempaquetarDatos
llamarServicios
enviarResultados
llama
llama
Servidor
Cliente
inicializarse
ejecutarCicloPrincipal
ejecutarServicio
utilizarAPIBroker
llamarServidor
inicializarTarea
utilizarAPIBroker
Figura 7.8 - Diagrama de clases del patrn Broker
Si aplicamos a nuestro caso de estudio cada componente del patrn los mismos,
estaran ubicados de la siguiente forma en el esquema:
PROXY DEL
LADO DEL
CLIENTE (A)
CLIENTE (A)
BROKER
PROXY DEL
LADO DEL
SERVIDOR
CASA MATRIZ
Suc 1
SERVIDOR
Sistema de Escaneo
de Cheques
Server de
la Sucursal
Host_Central
Servidor Central
CLIENTE (B)
PROXY DEL
LADO DEL
CLIENTE (B)
SERVIDOR
Figura 7.9 - Distribucin de los componentes del patrn Broker.
Ahora veremos un diagrama de secuencia que representa la interaccin entre los

componentes del sistema.
En este diagrama se ve el caso en que el usuario realiza la apertura del da:
1. Se inicia la aplicacin usuario. Durante la ejecucin del programa, el usuario invoca
un mtodo de un objeto servidor remoto solicitndole la fecha del da.
2. La aplicacin usuario solicita proxy cliente la fecha del da para realizar la apertura.
3. El proxy cliente empaqueta los datos y reenva la solicitud al broker.
4. El broker localiza el servidor al cual se esta realizando la peticin, en este caso al
Host Central. Puesto que el servidor esta disponible localmente, el broker enva el
mensaje al proxy servidor correspondiente.

Pag 94
5. El proxy servidor desempaqueta todos los parmetros e informacin relevante, e

invoca el servicio apropiado.
6. Despus que la ejecucin del servicio se completa, el servidor regresa el resultado al
proxy servidor, el cual lo empaqueta en un mensaje con informacin relevante, y lo
pasa al broker.
7. El broker enva la respuesta al proxy cliente.
8. El proxy cliente recibe la respuesta, desempaqueta el resultado y lo regresa a la
aplicacin usuario. Obteniendo de esta manera la fecha del da. El proceso cliente
contina con sus operaciones.
Cliente
Proxy del Cliente

Llamar
servidor
Envia Solicitud
De apertura de dia
Proxy del
Servidor
Broker
Servidor
Empaquetar
datos
Reexpedir
Solicitud
Encontrar
Servidor
Host Central
Desempaquetar
datos
Llamar_servicio
Ejecutar servicio de
apertura de dia
Enviar fecha del da
Empaquetar
datos
Reexpedir respuesta
Encontrar
cliente
Regresar
Desempaquetar
datos
Recibe resultados
Figura 7.10 - Diagrama de secuencia de la interaccin entre componentes
A continuacin se integra el patrn Model-View-Controller en el patrn Broker.

Si bien existen dos patrones arquitectnicos Model-View-Controller (MVC) y
Presentation-Abstraction-Control (PAC) que son aplicables a sistemas interactivos,
segn la clasificacin 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 presentacin, abstraccin y control manteniendo una analoga parcial
con el patrn 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
abstraccin y presentacin. Es diferente del componente control del patrn MVC en
que pasa las actualizaciones realizadas a su agente PAC padre.
El componente abstraccin contiene los datos al igual que el componente modelo en el
patrn MVC. Sin embargo, l puede contener solo parte de la estructura de datos de la
aplicacin, y no juega un papel activo en la notificacin de los cambios.
El componente presentacin es exactamente igual que el componente vista en el
patrn MVC.
Cabe destacar que estos tres componentes forman cada uno de los agentes PAC, los
cuales a su vez forman una estructura jerrquica en forma de rbol de agentes
cooperando. Cada agente es responsable de un aspecto especifico de la funcionalidad
de la aplicacin, provocando que el sistema quede dividido en mltiples componentes
presentacin, abstraccin y control, por lo cual no fue el patrn elegido para el caso de
estudio propuesto, adems agrega innecesariamente una mayor complejidad en el
diseo.
En el diseo de nuestro caso de estudio finalmente se opt utilizar el patrn MVC por
las siguientes razones:
- El sistema tiene la funcionalidad central que no est distribuida sino se ubica en un
nico centro
- La misma informacin 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 slo la cantidad de cheques escaneados
por una sucursal, sin el detalle de cada uno de ellos).
Como se ha visto los elementos de este patrn son:
- Modelo: datos y reglas de negocio.
- Vista: muestra la informacin 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
Observador
actualizar()
Llamar
actualizar
Modelo
Vista
Conectar MiModelo
conserguirDatos MiControlador
Datos
SeteoDeObservers
conectar(Observador)
desconectar(Observador)
notificar()
conseguirDatos
Servicio()
inicializar (Modelo)
hacerControlador() crear
activar ()
mostrar()
Controlador
MiModelo
Manipular MiVista
display
inicializar (Modelo, Vista)

conectar manejarEventos()
llamada a servicios
Figura 7.11 - Diagrama de clases del patrn Model-View-Controller
En la siguiente figura se muestra cada componente del patrn en nuestro caso de

estudio:
Vista (A)
Modelo
Controlador (A)
CASA MATRIZ
Suc 1
Host_Central
Sistema de Escaneo
de Cheques
Server de
la Sucursal
Servidor Central
Vista (B)
Controlador (B)
Figura 7.12 - Distribucin de los componentes del patrn Model-View-Controller
Ahora veremos cual es la conducta dinmica de este patrn al realizar la conexin al

sistema tras ingresar clave y contrasea.
1. El usuario interacta con la interfaz de usuario (vista) de alguna forma, como
dijimos ingresando la clave y contrasea.
2. El controlador recibe, por parte de los objetos de la vista, la notificacin de accin
solicitada por el usuario. El controlador gestiona el evento que llega a travs de un
manejador de eventos.
3. El controlador accede al modelo, actualizndolo con la accin solicitada por el
usuario, es decir, interpreta el evento y activa el procedimiento de validacin y
verificacin de clave y contrasea en el modelo.
Pag 97
4. El modelo realiza el servicio requerido.

internos.
Esto produce un cambio en sus datos
5. El modelo notifica del cambio a todas las vistas y controladores registrados con el
mecanismo de propagacin de cambios, llamando a sus procedimientos de
actualizacin.
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
Manejador
de eventos
Modelo
Vista
servicio
notifica
actualiza
display
Toma_datos
actualiza
Toma datos
Figura 7.13 - Diagrama de secuencia para la conexin 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 comunicacin nos lleva a estructurar dichos componentes en capas
mediante la utilizacin del patrn Layers.
Se tom la decisin de hacer uso de este patrn debido a que claramente se observa
la necesidad de comunicacin entre los distintos componentes lo cual nos lleva a
pensar que deberamos independizar la tarea de comunicacin de las tareas del
Pag 98
sistema operativo. Separando dos capas independientes, una capa de nivel ms bajo
que realice las tareas especficas de comunicacin 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 integracin final de todos los patrones sera:
Broker
Layer
S.O
Cproxy
Cliente
Vista
Controlador
Comunicaciones
Sproxy
Servidor
Modelo
Figura 7.14 - Integracin del patrn Broker, Model-View-Controller y Layers.
Capa Sistema Operativo: Es la capa de software que permite gestionar los mecanismos
de comunicacin, independizar el servicio de su implantacin y de los protocolos de
comunicaciones, adems, 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 Comunicacin: En esta capa se encuentra el protocolo de comunicacin, 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 aplicacin ms del patrn
Layers.
La principal ventaja de la estructuracin por capas es que cada capa cumple con
funciones y servicios determinados que brinda a la otra capa, esto permite una mejor
organizacin.
Tambin aplicamos el patrn Layers para desarrollar la tarea de acceso a datos en el
servidor. Se identifican las capas:

Pag 99
Capa de Servicio
Capa de Acceso a Datos
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

mtodo de un componente. Para los procesos ms complejos que requieren varios
pasos y transacciones de ejecucin larga, la aplicacin necesita disponer de un modo
de organizar las tareas y almacenar el estado hasta que el proceso se haya
completado. Adems, permite realizar el uso directo por parte de componentes de
presentacin o su encapsulacin como servicio y llamada a travs de una interfaz de
servicios, que coordina la conversacin 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 mtodos
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 especfica. Esta capa es
fundamental para que los cambios de base de datos no afecten a la aplicacin en
general.
Puede utilizar un componente de acceso a datos para centralizar la administracin de
la conexin y todo el cdigo relacionado con un origen de datos.
Se realiza la implementacin 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 arquitectnico de nuestro caso de estudio, el prximo
paso a seguir es el desarrollo del diseo del componente modelo del patrn ModelView-Controller aplicado anteriormente.
De acuerdo a nuestro anlisis previo, el modelo se conforma por tres componentes que
interactan entre s.
- Deposito de Cheques se encarga de la tarea de realizar y reflejar el depsito de los
cheques en sucursales y su posterior envo y del proceso de rechazo de los mismos.

Pag 100
- Recepcin de Cheques es el encargado de la recepcin y procesamiento de los

cheques recibidos, gestin de cobro y rechazo de cheques.
- Reclamos de Cheques efecta la carga y procesamientos del envo de reclamos, as
como tambin el la recepcin y gestin de imgenes a enviar.
MODELO
Deposito de Cheques
Solicita imagen
Reclamos de Cheques
Solicita imagen
Recepcin de Cheques
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 enva archivos desde y hacia el Sistema
Centralizador.
Sucursal
Banco
apertura ()
generarArchEnvio ()
generarArchImgRech()
generarArchRechazo ()
cierre()
...
Figura 7.17 - Clase Sucursal
Cuenta: Representa una cuenta bancaria de una sucursal de banco. Posee uno o ms
titulares que son Clientes del Banco, tipo de moneda y tipo de cuenta. Entre otras
cosas, es responsable de procesar depsitos y extracciones.
Cliente
Cuenta
Sucursal
numero
TipoMoneda
TipoCuenta
extraer()
depositar()
saldo()
puedoDebitar ()
debitar()
acreditar()
existeCuenta()
apertura ()
generarArchEnvio ()
generarArchImgRech ()
cierre()
...
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.
Cuenta
Cheque
numero
numero
importe()
fechaEmision()
puedeDebitar ()
debitar()
miCuenta
extraer()
depositar()
saldo()
puedoDebitar ()
debitar()
acreditar()
existeCuenta()
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. Adems de la informacin propia del cheque, conoce la cuenta en la que se
deposit, y es responsable de generar el registro con su informacin para enviar al
sistema centralizador, procesar el depsito o el rechazo segn lo que ocurra.
Para modelar el cheque depositado en otra sucursal, podramos 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 dinmicamente sea considerado como cheque
depositado. Por ello, la subclasificacin no es la forma ms adecuada de representarlo,
siendo la composicin la mejor manera.
Cuenta
numero
extraer()
depositar()
saldo()
puedoDebitar ()
debitar ()
acreditar()
existeCuenta()
cuentaDeposito
miCuenta
ChequeOtraSucursal
Cheque
numero
miCheque
importe()
fechaEmision()
puedeDebitar ()
debitar()
generarRegistro ()
procesarRechazo()
asociarImagen()
Figura 7.20 - Clase ChequeOtraSucursal.
Para generalizar ms este esquema y dar la posibilidad a que un cliente pueda trabajar
indistintamente con un Cheque o con un Cheque Depositado, aplicamos el patrn
Decorator.
Pag 102
Cheque
Cuenta
numero
numero
miCuenta
..
importe()
fechaEmision()
puedeDebitar ()
debitar ()
ChequeNormal
ChequeDepositado
numero
numero
acreditar()
importe()
fechaEmision()
puedeDebitar ()
debitar()
ChequeOtraSucursal
Cuenta
cuentaDeposito
numero
..
importe()
^miCheque.importe()
generarRegistro ()
procesarRechazo ()
asociarImagen ()
Figura 7.21 - Aplicacin Patrn 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 separacin 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 patrn Decorator, en los diagramas subsiguientes
utilizamos la interfaz cheque sin representar sus subclases para dar mayor simplicidad
al esquema del modelo.
Depsito de Cheques
Aqu se modelizan los procedimientos del depsito de un cheque, desde su registracin
por caja y digitalizacin hasta el procesamiento y generacin de archivo para su
posterior envo al Sistema Centralizador al efectuar el cierre de operaciones en la
sucursal. As como tambin la apertura y recepcin de los rechazos correspondientes a
cheques depositados y enviados el da anterior.
Al efectuar el depsito de un cheque por caja, se cargan todos los datos referentes a la
boleta y al cheque. El depsito 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, dlares, euros, etc.), sucursal y nmero. 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 depsito.
En caso de que el cheque corresponda a una cuenta de la sucursal donde se realiza el
depsito, 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 digitalizacin, quedando el cheque en estado
depositado.
Cada cheque tiene en su parte inferior un cdigo de barras que, al ser digitalizado,
permite la captura automtica del banco, sucursal, cdigo postal, nmero de cheque y
nmero cuenta al que pertenece el cheque, restando slo la tarea de completar en
forma manual su importe, quedando de esta forma generado el registro electrnico del
cheque con su imagen digitalizada.
Al finalizar el da, 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 envo,
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 Cmara Compensadora.
Al da siguiente, al realizar la apertura de operaciones en la sucursal, se reciben los
rechazos de los cheques depositados el da 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
realizacin de un movimiento de debito y crdito en la cuenta depositaria asociada,
provocando que el cheque cambie su estado a rechazado. Este proceso tambin
involucra el anlisis del cdigo de rechazo recibido. Si este cdigo implica generar
imagen se busca la imagen del cheque y se conforma un registro con la imagen.
Con la realizacin del cierre de operaciones en la sucursal, se genera un archivo con
las imgenes a enviar y este archivo es transferido al Sistema Centralizador.

Pag 104
Deposito de Cheques
Sucursal
Cliente
apertura()
cierre()
generarArchEnvio ()
generarArchImgRech()
...
numero
TipoMoneda
Banco
numero
Cuenta
extraer()
depositar()
saldo()
puedoDebitar ()
debitar ()
acreditar()
existeCuenta()
chequeOtraSucursal
sucursal:: apertura ()
RecepcionProcesamientoChequesRechazados()
RecepcionProcesamientoChequesPresentados()
RecepcionProcesamientoChequesReclamados()
TipoCuenta
miCuenta
cuentaDeposito
Cheque
ChequeOtraSucursal
RecepcionProcesamientoChequesRechazados()
Por cada cheque rechazado
Buscar Registro electrnico en ChequeOtraSucursal
Si lo encuentra
ChequeOtraSucursal.procesarRechazo()
sino
excepcion cheque no encontrado
finsi
numero
Estado
generarRegistro ()
miCheque procesar()
asociarImagen()
importe()
estado fechaEmision()
puedeDebitar ()
debitar ()
CodigoRechazo
Depositado
Estado
EnEspera
Figura 7.22 -
Rechazado
Imagen
Fecha
Aceptado
Depsito de Cheques
Recepcin de Cheques
El componente Recepcin de Cheques es el encargado de la recepcin y procesamiento
de los cheques recibidos, su imputacin monetaria y generacin 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 imputacin 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 cdigo 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
gestin.

Pag 105
Recepcin Cheques
Banco
Sucursal
Cliente
numero
Cuenta
...
apertura ()
cierre ()
...
numero
extraer()
depositar()
saldo()
puedoDebitar ()
debitar()
acreditar()
existeCuenta()
TipoMoneda
chequeOtraSucursal
TipoCuenta
ChequeOtraSucursal
miCuenta
cuentaDeposito
Cheque
Estado
estado
numero
miCheque
importe()
fechaEmision()
puedeDebitar ()
debitar()
Cheque:: 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
CodigoRechazo
Recibido
generarRechazo ()
procesarRegistro()
asociarImagen()
Imagen
Estado
RechazadoConCodigo
Fecha
Rechazado
Aceptado
Figura 7.23 - Recepcin de Cheques
Para los casos de la representacin y comportamiento de los cheques a travs de su

estado podramos hacer uso del patrn State, cuyo propsito permite cambiar
fcilmente el comportamiento de un objeto en tiempo de ejecucin. Los objetos son
estados, que se mantienen a travs de los atributos y el comportamiento que se define
en los mtodos. El comportamiento dinmico del objeto se alcanza delegando todas
las llamadas a mtodos que confan en ciertos valores para un objeto que representa
el estado y al modificar esos objetos tambin se obtiene un comportamiento diferente.
Una alternativa en lugar de la aplicacin del patrn State es la utilizacin de una
sentencia de seleccin mltiple como switch para decidir que tareas se realizan de
acuerdo al valor del estado que adopta el cheque. Al utilizar el patrn State ponemos
todo el comportamiento asociado a un estado en un objeto, evitando el uso de switch
monolticos para los diversos casos as como tambin la replicacin de cdigo,
permitiendo la incorporacin 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
envo 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 segn tenga un cdigo de rechazo asociado o no.

Pag 106
El comportamiento del cheque en la Recepcin de Cheques, tambin 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 situacin.
Un esquema de aplicacin del patrn State para representar los cambios de estados de
los cheques se muestra a continuacin.
CodigoRechazo
ChequeOtraSucursal
Estado
setEstado()
procesarRegistro()
procesar()
Recibido
procesar()
RechazadoConCodigo
procesar()
Fecha
Rechazado
procesar()
Aceptado
procesar ()
Figura 7.24 - Aplicacin del Patrn State en el Componente Recepcin de Cheques
Reclamos de Cheques
El componente Reclamo de Cheques es el encargado de la recepcin y procesamiento
de cheques reclamados tanto enviados como recibidos.
Al inicio del da, la sucursal recibe los reclamos que se han efectuado por otros bancos
para su procesamiento as como tambin las imgenes 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 electrnico. Si no corresponde, se genera el rechazo del reclamo. En ambos
casos al realizar el cierre de operaciones se envan los archivos al Sistema
Centralizador para su gestin.
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 da se envan 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 electrnico 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 separacin permite construir y
probar el componente modelo independientemente de la representacin visual. El
modelo tiene diversas vistas, cada una con su correspondiente controlador.
La vista maneja la visualizacin de la informacin 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 slo muestra la informacin referente a cheques
recibidos, enviados, rechazados y reclamados correspondientes a esa sucursal
especficamente.
La vista en el Sistema Centralizador muestra la informacin referente a cheques
recibidos, enviados, rechazados y reclamados de todas las sucursales.
Mientras la vista en las sucursales muestra informacin con un alto nivel de detalle
(cheque por cheque), la vista en el Sistema Centralizador slo muestra un resumen de
las transacciones realizadas por sucursal. Tambin se muestra el estado en que se
encuentra cada una de las sucursales (por ejemplo estado apertura del da, estado
consultando, estado escaneando, etc.)
El controlador interpreta las acciones del usuario informando al modelo y a la vista
para que cambien segn resulte apropiado.
Existe un controlador por cada vista, el cual permite relacionar la solicitud de servicio
realizada en la vista asocindola 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 travs
del controlador una peticin de servicio al modelo que ser una llamada al mtodo
existeCuenta(). El modelo ejecuta el mtodo y notifica del resultado de la verificacin
a la vista y controlador registrados con el mecanismo de propagacin de cambios. Una
vez finalizada esta notificacin vuelve a tomar el control el controlador.
El mecanismo de propagacin de cambios realizado aqu se lleva a cabo a travs de la
implementacin del patrn de diseo Observer. Este patrn 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 patrn cumple el rol de subject, quien contiene mtodos

mediante los cuales cualquier observer o vista se puede suscribir a l referencindose a
as mismo. El subject mantiene una lista de sus observers.
Los observers deben implementar mtodos 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 patrn de diseo Observer con los componentes del
patrn arquitectnico Model-View-Controller, determinamos que el componente modelo
es quien cumple el papel del subject y los componentes vista y controlador actan
como observers.
Un ejemplo de aplicabilidad del patrn Observer es cuando se reciben los archivos de
imgenes por reclamo o por rechazo y se notifica a las sucursales la recepcin de las
mismas informando que estn a disposicin para su toma y procesamiento.
Subject
Observer
aadir(Observer)
eliminar(Observer)
notificar()
avisar()
observer do: {
:each|each avisar]
ConcreteSubject
ConcreteObserver
estado
obtenerEstado()
definirEstado()
estadoObserver
estadoObserver= subject->obtenerEstado ();
avisar()
return estado;
Figura 7.25 - Patrn Observer

Pag 109

Caso Arquitectura

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Caso Arquitectura

Cargado por

Copyright:

Formatos disponibles

Captulo 6

Caso de estudio: Sistema de Cheques

Refundicin de los archivos recibidos de las Entidades Depositarias y

Refundicin de los archivos de rechazos recibidos de las Entidades

Arquitectura de Software: Estilos y Patrones

Figura 6.1 - Esquema a gran escala

Esquema solucin dentro de cada Entidad:

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

Arquitectura de Software: Estilos y Patrones

Definicin del Sistema

Arquitectura de Software: Estilos y Patrones

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

Circuito de Imgenes por Rechazo

Figura 6.4 - Circuito de Imgenes por rechazo

Arquitectura de Software: Estilos y Patrones

Circuito de Imgenes por Reclamos

- Rechazo de Imgenes por reclamo: en caso de recibir imgenes de la Entidad

Figura 6.5 - Circuito de Imgenes por reclamo

Limites del sistema

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Deposito por Caja

Pago o Rechazo segn

Generacin y envo de archivo de

Imputacin de cheques (Crdito)

Imputacin de cheques (Crdito y

Generacin de archivo con

Procesar rechazo de imgenes

Generar rechazo de imgenes

Figura 7.1 - Circuito de Depsito de Cheques

el archivo conteniendo todos los cheques a enviar a la Entidad

- Aceptado: en este caso, la Entidad Depositaria al da siguiente al no recibir rechazo,

Arquitectura de Software: Estilos y Patrones

Recepcin y procesamiento de archivo

Generar archivo de reclamo

Buscar imagen correspondiente al

Generar rechazo de reclamo

Recibir archivo con imgenes

Generar archivo con imagen

Imagen vlida para

Generar rechazo de imgenes

Figura 7.2 - Circuito de Reclamos de Cheques

Arquitectura de Software: Estilos y Patrones

La posibilidad de efectuar reclamos se puede realizar sobre cualquier tipo de cheque

Modelo de casos de uso

Arquitectura de Software: Estilos y Patrones

En los procesos se identifican dos actores: Usuario y Sistema Centralizador. El primero

Cheques rechazados recibidos

- Realizar el cierre del da provocando la generacin y envo de los archivos

Bsqueda de informacin: (Utilizado por el usuario)

Arquitectura de Software: Estilos y Patrones

Depsito de cheques: (Utilizado por el usuario):

Figura 7.3 - Diagrama de casos de uso

Arquitectura de Software: Estilos y Patrones

Figura 7.4 - Patrn Broker

Figura 7.5 - Patrn Broker

- Patrn Layers: Independencia de plataforma.

Nos interesa poder descomponer todo

Figura 7.6 - Patrn Layers

Figura 7.7 - Integracin del patrn Broker, Model-View-Controller y Layers

La distribucin es preferente, por lo cual, Broker es el primer patrn a aplicar ya que el

Arquitectura de Software: Estilos y Patrones

Para el cliente es transparente la forma de comunicacin entre los componentes,