Octopussy - Marcela Acero

Documento de Arquitectura de Software
Octopussy FINANCIAL TECH SOLUTIONS

Versin 1.0
OCTOPUSSY Documento: Documento de Arquitectura de Software Clave: Octopussy_ArquitecturaSoftware_070611_v1.doc Versin: 1.0 Fecha: 01/06/2011
Historial de Revisin
Fecha
07 DE JUNIO DE 2011
Versin
1.0
Descripcin
PRIMERA ENTREGA DE LA ARQUITECTURA PARA OCTOPUSSY
Autor
INGRID MARCELA ACERO GARCA
Confidential
FINANCIAL TECH SOLUTIONS
Pgina 2
Tabla de contenido
1. Introduccin 1.1 1.2 1.3 1.4 1.5 2. 3. 4. 5. Propsito Alcance Definiciones, Acrnimos, y Abreviaturas Referencias Panorama General 4 4 4 Error! Marcador no definido. 4 5 6 7 9 14 15 16 Error! Marcador no definido. 26 27 28 Error! Marcador no definido. 28 29 29 30 39
Representacin Arquitectnica Objetivos Arquitectnicos y Restricciones Escenarios Clave Vista Lgica 5.1 5.2 Diagrama de Clases Realizacin de Clases
6.
Vista de Procesos 6.1 6.2 Diagrama por Capas Diagrama de Componentes
7.
Vista de Despliegue 7.1 7.2 Diagrama por Niveles Diagrama de Despliegue
8.
Vista 4+1 o de Casos de Uso 8.1 8.2 Diagramas de Casos de Uso Arquitectnicamente Relevantes Realizacin de Casos de Uso
9.
Recomendaciones
Confidential
Pgina 3
1.
Introduccin
En este documento se mostrar detalladamente el modelo de las 4 + 1 vistas del sistema Octopussy, en donde se describe cmo se comporta cada una de las vistas con sus respectivos diagramas detallando cmo se compondr la maravillosa herramienta Octopussy que proveer al usuario (en este caso las entidades bancarias) la posibilidad de ampliar sus horizontes y tener la claridad a la hora de desarrollar el modelo y tener una percepcin clara desde todos los puntos acerca del comportamiento.
1.1 Propsito Este documento provee un panorama arquitectnico para describir diferentes aspectos del sistema, auxiliar en decisiones de arquitectura significantes con las cuales se ha construido el sistema. Aqu encontraremos las 4 +1 vistas como lo son: la vista Lgica, la vista de Procesos, la Vista Fsica, y la 4+1 en donde podremos encontrar los casos de uso. Se debe leer todo el documento ya que se espera que as se logre una mayor percepcin y posteriormente escoger la vista que ms se adecue a las necesidades de nuestra lectura. 1.2 Alcance El documento de Arquitectura de Software aplica para que las personas que lean el documento puedan entender con mayor claridad las formas en las que el sistema acta y varia; y sobretodo como se relacionan los componentes haciendo un sistema integral. 1.3 Referencias Artculo publicado en IEEE Software 12(6), Noviembre 1995. Traducido por Mara Cecilia Bastarrica en Marzo 2006
Confidential
Pgina 4
1.4 Panorama General Todos hemos visto muchos libros y artculos donde se intenta capturar todos los detalles de la arquitectura de un sistema usando un nico diagrama. Pero si miramos cuidadosamente el conjunto de cajas y flechas que muestran estos diagramas, resulta evidente que sus autores han trabajado duramente para intentar representar ms de un plano que lo que realmente podr expresar la notacin. Es acaso que las cajas representan programas en ejecucin? O representan partes del cdigo fuente? O computadores fsicos? O acaso meras agrupaciones de funcionalidad? Las flechas representan dependencias de compilacin? O flujo de control? Generalmente es un poco de todo. Sera que una arquitectura requiere un estilo nico de arquitectura? A veces la arquitectura del software tiene secuelas de un diseo del sistema que fue muy lejos en particionar prematuramente el software, o de un nfasis excesivo de algunos de los aspectos del desarrollo del software: ingeniera de los datos, o eficiencia en tiempo de ejecucin, o estrategias de desarrollo y organizacin de equipos. A menudo la arquitectura tampoco aborda los intereses de todos sus clientes. Varios autores han notado este problema, incluyendo a David Garlan y Mary Shaw [7], Gregory Abowd y Robert Allen [1], y Paul Clements [4].
Confidential
Pgina 5
Representacin Arquitectnica
El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. La vista lgica describe el modelo de objetos del diseo cuando se usa un mtodo de diseo orientado a objetos. Para disear una aplicacin muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algn otro tipo de vista lgica, tal como diagramas de entidad-relacin. La vista de procesos describe los aspectos de concurrencia y sincronizacin del diseo. La vista fsica describe el mapeo del software en el hardware y refleja los aspectos de distribucin. La vista de desarrollo describe la organizacin esttica del software en su ambiente de desarrollo. Los diseadores de software pueden organizar la descripcin de sus decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta vista. La arquitectura evoluciona parcialmente a partir de estos escenarios.
Confidential
Pgina 6
2.
Objetivos Arquitectnicos y Restricciones

Identificar los casos de Uso arquitectnicamente relevantes (elaborar una lista). INSCRIPCIN Web Oficina Mail Fax Telfono Celular Identificar los Requerimientos No Funcionales y Atributos de calidad Una interfaz grfica amigable y de fcil uso para todo tipo de usuarios en todos los dispositivos y canales. No se requieren conocimientos avanzados en el rea de computacin para su utilizacin. Portabilidad: El sistema funciona en cualquier plataforma que se instale a nivel servidor. Confiabilidad: El sistema debe contar con encriptacin de datos de contraseas para asegurar que la inviolabilidad de las identidades de los usuarios y la informacin sensible que se transmite hacia y desde la plataforma. Esta seguridad debe garantizarse para todos y cada uno de los protocolos de comunicacin empleados por los diversos canales y dispositivos. Eficiencia: El sistema estar diseado de manera que trabaje lo ms rpido posible y con la menor cantidad de fallas, sern probadas diferentes versiones antes de hacer la implantacin definitiva a fin de corregir problemas que pudieran poner en riesgo la estabilidad del sistema. Mantenibilidad: El sistema, debe ser diseado con principios de modularidad que garanticen su fcil mantenimiento en todas las capas que lo conforman: aplicaciones clientes de cada dispositivo, estaciones, servidores, etc. Funcionalidad: El sistema ser sencillo de utilizar y no se considera necesaria una fase de entrenamiento para los usuarios, exceptuando el caso de aquellos muy inexpertos. El proceso de instalacin del mismo en los dispositivos de ser fcil y autnomo. Disponibilidad: se debe considerar mecanismos para garantizar una alta disponibilidad del sistema.
Identificar las restricciones Dado que se pretende comercializar OCTOPUSSY entre las entidades financieras de la regin, el desarrollo debe ser lo ms portable posible por lo que no se contempla el uso de tecnologas propietarias, y adems se debe incluir la posibilidad de localizar la interfaz de usuario de manera que pueda ajustarse al lenguaje o modismos de cada pas. Se debe tener en cuenta que el xito del proyecto radica en la facilidad de instalacin, manejo y configuracin de la solucin en todas sus presentaciones: en dispositivos, servidores, estaciones de trabajo, etc. Igual consideracin aplica para los temas relacionados con el licenciamiento y portabilidad de la aplicacin.
Confidential
Pgina 7
La solucin debe estar en capacidad de interactuar con los distintos medios de comunicacin empleados por cada uno de los canales, como canales privados de datos; los mencionados anteriormente para dispositivos celulares (WEB, WAP, SMS, USSD,); mensajera ISO8583, VPN etc. En cualquier caso, independientemente del medio elegido, la informacin siempre debe viajar de forma segura. El Sistema est pensado para soportar las transacciones vlidas para persona natural. No se descarta que en un futuro se ample la funcionalidad para las transacciones propias de personas jurdicas. Tambin se debe considerar que Octopussy en un futuro soporte transacciones para otros servicios o productos financieros como CDTs. Identificar los Objetivos de la Arquitectura Identificar las metas de la Arquitectura o La meta de la arquitectura es: Creating a complete application desing. Identificar a quines va dirigida la Arquitectura o Diseadores o Programadores o Entidades Financieras o Staff o Proveedores de tecnologa o Gerentes TI Identificar las restricciones: o Arquitectnicamente Relevantes: Alto nivel de uso por usuarios y stakeholder Interseccin entre funcionalidad y atributos de calidad Escenarios desconocidos. Opciones y Restricciones de tecnologa Alto grado de portabilidad o Plataforma o Dispositivos Localizar interfaz Facilidad de instalacin Licenciamiento ISO 8583 Escalabilidad Disponibilidad Otras restricciones Alcance & Tiempo Se cuentan con 2 semanas para realizar la arquitectura.
Confidential
Pgina 8
3.
Escenarios Clave
En los escenarios clave tendremos:
COMPRAS POR E MAIL
TRANSFERENCIA POR CELULAR
Confidential
Pgina 9
RETIRO EN CAJERO AUTOMATICO
RECARGAS POR TELEFONO
Confidential
Pgina 10
PAGOS EN CORRESPONSAL NO BANCARIO
GIROS POR LA WEB
Confidential
Pgina 11
TRANSFERENCIA EN OFICINA
PAGOS EN KIOSKO
Confidential
Pgina 12
Identificar y relacionar los Estilos Arquitectnicos que seran empleados en el modelo Cliente-servidor. Donde el software reparte su carga de cmputo en dos partes independientes pero sin reparto claro de funciones. Arquitectura de tres niveles. Especializacin de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentacin (interfaz de usuario), otra para el clculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relacin con la siguiente. Identificar y relacionar tecnologas relevantes WEB Plataforma Java pues es la ms comn en dispositivos y se cubre la mayor parte de los clientes. Identificar y relacionar los Asuntos transversales (Crosscutting Concerns) El usuario elegir los canales que desee usar y se le entregar un cdigo de acceso al canal que siempre ir seguido por una pregunta de confirmacin acerca de un tema aleatorio. El usuario siempre recibir un mensaje de texto a su celular personal con la informacin del movimiento realizado y el valor de la transaccin. El sistema siempre guardar un historial de los movimientos siempre especificando el canal por el cual se realiz la transaccin.
Confidential
Pgina 13
4.
Vista Lgica
Es importante aclarar para esta arquitectura, los componentes internos de los paquetes y sus relaciones. El paquete canales
pkg Canales EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
Telefono EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada Oficina
CNB
EA 8.0 versin de prueba no registrada -EAasesor: Asesor de prueba no registrada EA 8.0 versin de prueba no registrada 8.0 versin EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
Celular Kiosko EA 8.0 versin de pruebaint registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada no operador: + env io_operador() : v oid EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada Cajero_auto EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
Web Mail_fax
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada Call_center EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
+ env io_transaccion() : v oid + v erifico_reglas_canal() no EA 8.0 versin de prueba: v oidregistrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada transaccion: int Tarjeta
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
El paquete transacciones
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
pkg Transacciones

Compras

Giros Recargas
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
Pagos Retiros
Consultas EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada Transferencias
Otros_convenios Remesas
Confidential
Pgina 14
4.1 Diagrama de Clases

class Octopussy
Menu + menu menu_bar: menuBar carga_menu() : v oid Entidad_Bancaria + + Ejecutador + + canal clav e cliente cuenta entidad: int v erificar_entidad() : boolean v erificar_usuario() : boolean Canales_activos + + + cajero_auto canal celular CNB fax kiosko mail Oficina telefono activ a_canal(int) : v oid desactiva_canal(int) : v oid verfica_canal(int) : v oid + Start Cuenta abstract Persona + + + apellido cedula: int nombre v erifica_apellido() : boolean v erifica_cedula() : boolean v erifica_nombre() : boolean Cajero + Asesor cuenta v erifica_cuenta() : boolean Protocolo8583 + + canal cliente transaccion Bloqueo ejecuta(int) : v oid v erifica_info() : v oid Transacciones + + + + + + + + + Compras Consultas Giros Otros_conv enios Pagos Recargas Remesas Retiros Transferencias entidad v erificar_canales_entidad() v erificar_entidad() Canales + + + + + + + + + + Cajero_auto Call_center Celular CNB Kiosko Mail_fax Oficina Tarjeta Telefono W eb
Usuario + clave cliente cuenta verifica_cliente() : boolean
Inscripcion Cliente + + + + cliente cuenta aprobacion() : boolean v erificar_clav e() : boolean v erificar_cliente() : boolean v erificar_Cuenta() : boolean + + canal activ ar_canal() desactiv ar_canal()
Transaccion transaccion ejecuta_transaccion() : v oid
Confidential
Pgina 15
4.2 Realizacin de Clases
Nombre de la Clase: <public> Menu Superclases:
concreta Del sistema
Atributos y relaciones: Servicios:
Carga_menu, men_bar ; se relaciona directamente con el ejecutador Servidores:
Esta clase le agrega un men al programa Reglas: El men cambia de acuerdo con los permisos que tenga el usuario
Nombre de la Clase: <public> Usuario Superclases:
concreta Del dominio
Atributos y relaciones: Servicios: Esta clase se relaciona con el cliente, lo verifica
Los atributos clientes, clave, cuenta se relaciona con la clase cliente Servidores: Bases de datos Octopussy
Reglas: Verifica si el cliente y la cuenta son validos
Nombre de la Clase: Ejecutador Superclases:
Atributos y relaciones: Servicios:

Esta clase aplica las reglas de la entidad y lo aplica al cliente y al sistema
Canal, clave, cuenta, cliente, entidad, se relaciona con el Start del sistema; y la entidad bancaria Servidores:
Reglas: Se debe verificar primero el cliente.

Confidential FINANCIAL TECH SOLUTIONS Pgina 16
Nombre de la Clase: <public> Entidad_bancaria Superclases: Atributos y relaciones: Servicios: Esta clase verifica las entidades asociadas y las reglas a las que aplican
Se relaciona con el ejecutador Servidores: Base de datos de Octopussy
Reglas: se debe tener conexin a la base de datos Octopussy para verificar cuales entidades bancarias pertenecen al sistema.
Nombre de la Clase: <public> Cliente Superclases: Atributos y relaciones: Servicios: Esta clase verifica cada parte del cliente, la clave el nombre y las cuentas que posee
concreta Del dominio Persona Se relaciona con el usuario Servidores: Core Bancario
Reglas: Se debe tener los datos del cliente
Nombre de la Clase: <public> Canales_Activos Superclases: Atributos y relaciones: Servicios: Esta clase verifica que canales estn activos y los activa y desactiva segn la clase inscripcin
Se relaciona con el start, la inscripcin Servidores:
Base de datos Octopussy
Reglas: Se deben tener la conexin a base de datos Octopussy
Confidential
Pgina 17
Nombre de la Clase: <public> Inscripcin Superclases: Atributos y relaciones: Servicios: Determina si empieza la aplicacin o no Reglas:
Se relaciona con los canales activos Servidores:
Nombre de la Clase: <public> Start Superclases: Atributos y relaciones: Servicios: Empieza la aplicacin, a este punto ya todas las validaciones estn hechas Reglas: se debe pasar por los canales_activos Se relaciona con los canales_activos Servidores:
Nombre de la Clase: <public> Cuenta Superclases: Atributos y relaciones: Servicios: Verifica las condiciones Reglas:
Se relaciona con cliente Servidores:
Confidential
Pgina 18
Nombre de la Clase: <public> Persona Superclases:
abstracta Del dominio
Atributos y relaciones: Servicios: Provee los mtodos bsicos para una persona en el sistema Reglas:
Se relaciona con las tres clases que heredan, cliente; asesor; cajero Servidores:
Nombre de la Clase: <public> Asesor Superclases: Atributos y relaciones: Servicios: Verifica la veracidad de un asesor y le otorga permisos Reglas: Persona
Se relaciona con persona Servidores:
Confidential
Pgina 19
Nombre de la Clase: <public> Cajero Superclases: Atributos y relaciones: Servicios: Verifica la veracidad de un cajero (humano) y le otorga permisos Reglas: Persona
Se relaciona con persona Servidores:
Nombre de la Clase: <public> Bloqueo Superclases: Atributos y relaciones: Servicios: Bloquea la aplicacin para el canal con el usuario Reglas:
Se relaciona con las reglas del protocolo 8583 Servidores:
Nombre de la Clase: <public> Protocolo_8583 Superclases: Atributos y relaciones: Servicios: Se comunica con el Core Bancario Reglas:
Se relaciona directamente con el core Servidores: Core bancario
Confidential
Pgina 20
Nombre de la Clase: <public> Transaccion Superclases: Atributos y relaciones: Servicios: Gestiona la comunicacin entre los canales y las transacciones Reglas:
se relaciona con los canales y las transacciones Servidores:
Confidential
Pgina 21
5.
Vista de Procesos
sd CNB-pagos
Corresponsal no bancario Cliente

tarjeta() solicita()
Internet
Octopussy
Core Bancario Receptor
firewall() firewall()
El Receptor puede ser una persona natural o una entidad

verifica()
pago() respuesta()
respuesta()
sd Caj eroauto_retiro
Cajero Automatico Cliente
Octopussy
Core Bancario
Tarjeta()
FIREWALL()
FIREWALL()
VERIFICA()
DINERO()
Confidential
Pgina 22
sd Kiosko-pagos
KIOSKO Cliente
Octopussy
firewall() firewall()
verifica()
pago()
notificacion()
sd Oficina-transferencias
Oficina Cliente
Octopussy
firewall()
firewall()
verifica()
transferencia()
notificacion()
Confidential
Pgina 23
sd Celular-transferencia
Operador Cliente
SMS()
Octopussy
FIREWALL()
FIREWALL()
VERIFICA()
SMS()
sd Telefono-recargas
Call Center Cliente

llama()
Octopussy
Core Bancario
Operador
firewall()
firewall() verifica()
respuesta()
Confidential
Pgina 24
OCTOPUSSY Documento: Documento de Arquitectura de Software Clave: Octopussy_ArquitecturaSoftware_070611_v1.doc

sd Mail-compras
Versin:
1.0
Fecha: 01/06/2011
Call Center Cliente

MAIL() firewall()
Octopussy
firewall()
verifica()
MAIL()
sd Web-giros
Internet Cliente
Octopussy
WEB()
firewall()
firewall()
verifica()
notificacion()
Confidential
Pgina 25
6.
Vista de Desarrollo
6.1 Diagrama por Capas

cmp Capas
INTERFAZ
Lgica CNB Lgica Mail Lgica Kiosko Lgica Oficina Lgica Telfono Lgica Web Lgica Celular Lgica Cajero Automtico
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada seguridad
MENU EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada CONEXION
EA 8.0 versin de prueba no HTTP registrada EA 8.0 versinSMS prueba no registrada EA 8.0 versin de prueba no registrada de MSMS HTTPS IMAP POP3 Menu
TRADUCCION DE LENGUAJE
REGLAS DE NEGOCIO
TXT TXT TXT TXT TXT retiros TXT TXT TXT otros
giros EA 8.0 versin de prueba no registradaTXT EA 8.0 pagos versin de prueba no registrada EA 8.0 versin de prueba no registrada Remesas consultas Compras trasferencias recargas convenios
TRADUCTOR 8583
Core envio y respuesta
Confidential
Pgina 26
6.2 Diagrama de Componentes

cmp componentes
Interfaz + + + + + + + + Lgica Cajero Automtico Lgica Celular Lgica CNB Lgica Kiosko Lgica Mail Lgica Oficina Lgica Telfono Lgica W eb
Conexion + + + + + + + + + ATM HTTP HTTPS IMAP MSMS POP3 SMS TCP UDP
Seguridad
Menu
Traduccin Lenguaje
Reglas Negocio + + + + + + + + + TXT Compras TXT consultas TXT giros TXT otros conv enios TXT pagos TXT recargas TXT Remesas TXT retiros TXT trasferencias
Traductor 8583 Conexion
Confidential
Pgina 27
7.
Vista de Despliegue
7.1 Diagrama de Despliegue
deployment Despliegue
KIOSKO CELULAR
Interfaz Interfaz M enu Envio SM S M enu HTTPS Interfaz Traduccion Lenguaje Traductor Traductor 8583 Core envio y respuesta 8583
CNB
M enu HTTPS Interfaz Reglas negocio Core envio y respuesta Traduccion Lenguaje Traductor 8583 Reglas negocio Core envio y respuesta
OFICINA
M enu HTTPS
Reglas negocio Core envio y respuesta
Traduccion lenguaje Traductor 8583
Traduccion lenguaje
Reglas negocio
Conexion Core Seguridad
BD Octopussy
WEB
Interfaz M enu HTTPS
CAJERO AUTOMATICO TELEFONO MAIL

HTTPS Interfaz Registro datos POP3 Interfaz M enu ATM
Traduccion lenguaje
Reglas de negocio
Interfaz
M enu
Traduccion lenguaje Traductor 8583
Reglas de negocio
Traductor 8583
Traduccion lenguaje
Reglas de negocio Traduccion lenguaje Traductor 8583 Reglas negocio Core envio y respuesta Core envio y respuesta
Traductor 8583
Confidential
Pgina 28
8.
Vista 4+1 o de Casos de Uso
8.1 Diagramas de Casos de Uso Arquitectnicamente Relevantes

uc Celular transferencia
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regi
OCTOPUSSY Envio solicitud
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regi Acceso a
Octopussy Usuario transaccion
Aceptar EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regi
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EACORE versin de prueba no regi 8.0 BANCARIO
Transferencia
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regi RECEPTOR
Confidential
Pgina 29

uc Telefono-recargas
Versin:
1.0
Fecha: 01/06/2011
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg
OCTOPUSSY
Envio solicitud
Acceso EA 8.0 versin de prueba no registrada EAa8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no Aceptar registrada EA 8.0 versin de prueba no reg
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg CORE BANCARIO
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg Compras OPERADORES
CELULARES
uc Web-giros
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis Acceso a
Aceptar EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EACORE versin de prueba no regis 8.0 BANCARIO
Giros
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis RECEPTOR
Confidential
Pgina 30
uc Oficina - transferencia
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis Acceso a
Aceptar EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EACORE versin de prueba no regis 8.0 BANCARIO
Transferencia
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis RECEPTOR
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no regis EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg
uc Mail- COMPRAS
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg OCTOPUSSY
Envio solicitud
Octopussy
Acceso a EA 8.0Usuario de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg versin
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no Aceptar registrada EA 8.0 versin de prueba no reg
transaccion
CORE BANCARIO EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg ENTIDADES
AFILIADAS PAGOS Compras
Confidential
Pgina 31
uc Kiosko - pagos
OCTOPUSSY
Envio EA 8.0 EA 8.0 versin de prueba no registrada solicitud versin de prueba no registrada EA 8.0 versin de prueba no reg
Acceso a Aceptar CORE BANCARIO
Octopussy EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg Usuario
transaccion EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg
ENTIDADES
EA 8.0 versin de prueba no registrada Pagos 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg EA AFILIADAS PAGOS
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no reg EA 8.0 versin de uc Caj ero Automatico retiro prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
OCTOPUSSY EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada
Envio solicitud
Acceso a Octopussy
Aceptar
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada transaccion
Usuario CORE BANCARIO
EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada Retiros
Confidential
Pgina 32

uc CNB pagos
Versin:
1.0
Fecha: 01/06/2011
Octopussy
EA 8.0 versin de prueba no registrada Acceso a versin de prueba no registrada EA 8.0 versin de prueba no regi EA 8.0
Aceptar transaccion
Usuario Pagos
CORE BANCARIO
Confidential
Pgina 33
8.2 Realizacin de Casos de Uso 8.3 Conjunto de Casos de Uso
Informacin de la versin
Proyecto: Nmero Interno de Versin: Documentos Relacionados: OCTOPUSSY 1.0
Casos de Uso por rea Funcional

Casos o o o o o o o o de Uso CU-00 CU-01 CU-02 CU-03 CU-04 CU-05 CU-06 CU-07 Arquitectonicamente Relevantes CNB pagos Cajero Automatico retiro Kiosko pagos Mail compras Oficina transferencia Telefono recargas Web Giros Celular transferencia
8.4 Use Case Suite > Use Cases
Release Information
Project: Internal Release Number: Related Documents: OCTOPUSSY
Default Aspects of All Use Cases

Direct Actors: Stakeholders: Prereq: Cliente cuenta corriente Octopussy Entidades bancarias, programadores EL usuario debe tener cuenta en la entidad
UC-00: CNB pagos

Summary: Priority:
Confidential
El usuario llega a un corresponsal no bancario a realizar un pago, Essential

FINANCIAL TECH SOLUTIONS Pgina 34
Use Frequency: Direct Actors: Main Success Scenario:
Normal Administrador del sistema, asesor de corresponsal 1. 2. 3. 4. 5. El cliente visita el CNB solicita la realizacion del pago El asesor del corresponsal envia los datos al aceptador El aceptador envia los datos al core por el protocolo 8583 Se genera la respuesta Se genera el pago
6.
Alternative Scenario Extensions: Notes and Questions
Si la cuenta no posee fondos se cancela el pago Si el usuario escribe la clave de forma incorrecta por 3 veces se bloquea el uso del canal
UC-01: Cajero Automatico retiro

Summary: Priority: Use Frequency: Main Success Scenario: El usuario retira dinero en un cajero automatico Essential Una vez por usuario 1. 2. 3. 4. 5. 6. El usuario se acerca al cajero ingresa su tarjeta debito marca su clave Se verificn los datos Se comunica con el core Se genera el retiro de dinero cuadre de cuentas
7.
Alternative Scenario Extensions: Notes and Questions
Si la cuenta no posee fondos se cancela el retiro Si el usuario escribe la clave de forma incorrecta por 3 veces se bloquea el uso del canal
UC-02: Kiosko pagos

Summary: Priority: Use Frequency: Main Success Scenario: El usuario se acerca al kiosko y genera un pago Expected uno por usuario 1. El cliente visita el Kiosko 2. solicita la realizacion del pago 3. El CNB envia los datos al aceptador
Confidential
4. El aceptador envia los datos al core por el protocolo 8583 5. Se genera la respuesta 6. Se genera el pago Notes and Questions Si el usuario escribe la clave de forma incorrecta por 3 veces se bloquea el uso del canal
UC-03: Mail compras

Summary: Priority: Use Frequency: Main Success Scenario: el Usuario desea realizar una compra por e-mail Expected uno por usuario 1. 2. 3. 4. 5.
6.
El cliente escribe los datos en el e-mail con el cod solicita la realizacion de la compra Un agente de call center envia los datos a Octopu El aceptador envia los datos al core por el protoco Se genera la respuesta Se genera la compra
UC-04: Oficina transferencia

Summary: Direct Actors: Priority: Use Frequency: Main Success Scenario: El usuario realiza una transferencia en una oficina Administrador del sistema Expected uno por usuario 1. El cliente se acerca a una oficina a realizar la transerencia 2. solicita la realizacion de la transferencia 3. Un cajero realiza la consulta de los datos del usuario 4. El aceptador envia los datos al core por el protocolo 8583 5. Se genera la respuesta 6. Se genera la transferencia
UC-05: Telefono recargas

Summary: Direct Actors: Priority:
Confidential
Se realiza una recarga celular por telefono Admin: Web-site administrator, operador celular Essential
Use Frequency: Main Success Scenario:
Uno por usuario 1. 2. 3. 4. 5. 6. El cliente se comunica con el call center solicita la realizacion de la recarga Un agente de call center envia los datos a Octopussy El aceptador envia los datos al core por el protocolo 8583 Se genera la respuesta Se genera la recarga Se envian los datos al operador celular
7.
UC-06: Web Giros

Summary: Priority: Use Frequency: Main Success Scenario: El usuario ingresa a la pagina a realizar un giro. Essential Sometimes 1. 2. 3. 4. 5. El cliente ingresa a la web solicita la realizacion de un giro Se envian los datos HTTPS El aceptador envia los datos al core por el protocolo 8583 Se genera la respuesta Se genera el giro
6.
Notes and Questions
Si el usuario escribe la clave de forma incorrecta por 3 veces se bloquea el uso del canal
UC-07: Celular Transferencia

Summary: Priority: Use Frequency: Main Success Scenario: El usuario realiza una tranferencia por celular Essential Often 1. El cliente ingresa al menu del celular 2. solicita la realizacion del giro 3. El Celular envia los datos al aceptador por medio de un SMS autoconstruido 4. El aceptador envia los datos al core por el protocolo 8583 5. Se genera la respuesta 6. Se genera el giro
Scenario Extensions:
Confidential
Pgina 37
Si el usuario escribe la clave de forma incorrecta por 3 veces se bloquea el uso del canal
Confidential
Pgina 38
9.
Recomendaciones
Hay que tener en cuenta para esta arquitectura que se deben generar paquetes que nos pueden ayudar a organizar y tener un mayor manejo de las clases y los mtodos; tambin es importante recordar que los diagramas aqu descritos son un ejemplo del funcionamiento de la aplicacin; se desarrollaron los casos de uso arquitectnicamente relevantes; se requiere buscar la misma lgica para los dems casos de uso.
Confidential
Pgina 39

Octopussy - Marcela Acero

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Octopussy - Marcela Acero

Uploaded by

Copyright:

Available Formats

Documento de Arquitectura de Software

Octopussy FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

Vista de Procesos 6.1 6.2 Diagrama por Capas Diagrama de Componentes

Vista de Despliegue 7.1 7.2 Diagrama por Niveles Diagrama de Despliegue

FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

Objetivos Arquitectnicos y Restricciones

FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

En los escenarios clave tendremos:

COMPRAS POR E MAIL

TRANSFERENCIA POR CELULAR

FINANCIAL TECH SOLUTIONS

RETIRO EN CAJERO AUTOMATICO

RECARGAS POR TELEFONO

FINANCIAL TECH SOLUTIONS

PAGOS EN CORRESPONSAL NO BANCARIO

GIROS POR LA WEB

FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

FINANCIAL TECH SOLUTIONS

EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada

EA 8.0 versin de prueba no registrada EA 8.0 versin de prueba no registrada

FINANCIAL TECH SOLUTIONS

4.1 Diagrama de Clases

Usuario + clave cliente cuenta verifica_cliente() : boolean

Transaccion transaccion ejecuta_transaccion() : v oid

FINANCIAL TECH SOLUTIONS

4.2 Realizacin de Clases

Nombre de la Clase: <public> Menu Superclases:

concreta Del sistema

Atributos y relaciones: Servicios:

Carga_menu, men_bar ; se relaciona directamente con el ejecutador Servidores:

Nombre de la Clase: <public> Usuario Superclases:

concreta Del dominio

Atributos y relaciones: Servicios: Esta clase se relaciona con el cliente, lo verifica

Reglas: Verifica si el cliente y la cuenta son validos

Nombre de la Clase: Ejecutador Superclases:

concreta Del dominio

Atributos y relaciones: Servicios:

Reglas: Se debe verificar primero el cliente.

concreta Del dominio

Se relaciona con el ejecutador Servidores: Base de datos de Octopussy

Reglas: Se debe tener los datos del cliente

concreta Del dominio

Se relaciona con el start, la inscripcin Servidores:

Base de datos Octopussy

Reglas: Se deben tener la conexin a base de datos Octopussy

FINANCIAL TECH SOLUTIONS

concreta Del dominio

Se relaciona con los canales activos Servidores:

concreta Del dominio

concreta Del dominio

Se relaciona con cliente Servidores:

FINANCIAL TECH SOLUTIONS

Nombre de la Clase: <public> Persona Superclases:

abstracta Del dominio

concreta Del dominio

Se relaciona con persona Servidores:

FINANCIAL TECH SOLUTIONS

concreta Del dominio