SAD1.0

Historial de Cambios
VERSION
FECHA
SECCION
MODIFICADA
DESCRIPCION
RESPONSABLE
0.1
09/04/09
Índices
Organización de
índices
Juan Sebastián
Figueredo
0.2
09/04/09
Sección 4
Adición de la
sección
Juan Sebastián
Figueredo
0.3
09/04/09
Sección 11
Adición de la
sección
Juan Sebastián
Figueredo
0.3.1
10/04/09
Casos de uso y
requerimientos
asociados
Adición de tablas
Juan Sebastián
Figueredo
0.3.2
10/04/09
Sección 9,10,11
Revisión de las
secciones
Felipe Caicedo
0.3.5
10/04/09
Todo
Revisión general
Juan Gabriel
Riveros
0.4
10/04/09
Sección 6
Adición de la
sección
Juan Sebastián
Figueredo
0.4.1
10/04/09
Sección 7
Adición de la
sección
Felipe Caicedo
0.4.2
13/04/09
Todo
Revisión general
Juan Gabriel
Riveros
0.4.5
13/04/09
Sección 4
Inserción de la
arquitectura
Juan Sebastián
Figueredo
0.5
13/04/09
Tablas e
ilustraciones
Corrección de
contenido
Todos
0.6
13/04/09
Todo
Corrección de
formato
Juan Gabriel
Riveros
0.7
13/04/09
Definiciones
Acrónimos y
Abreviaciones
Corrección de
contenido
Juan Gabriel
Riveros
1.0
13/04/09
Referencias
Adición de
Todos
Referencias
PREFACIO
Los requerimientos y la arquitectura son dos elementos esenciales entre los
productos relacionados con el software en el ciclo de vida. La Arquitectura de
software desde hace mucho tiempo ha sido reconocida por tener un profundo
impacto en los requerimientos no funcionales sobre la seguridad, tolerancia a
fallos, el rendimiento, etc. Así pues el SAD busca la estabilidad de la arquitectura
del negocio a pesar de la volatilidad de los requerimientos. Cuando una
organización y sus productos se hacen más grandes y más complicados la
arquitectura asume un papel más importante por lo tanto la forma de cómo las
organizaciones hacen uso de la arquitectura es un indicador importante de su éxito
en el desarrollo de sistemas complejos que cumplen con los requisitos en función
eficiente de los costos.
Tabla de Contenido
1.
2.
INTRODUCCIÓN ............................................................................................................. 12
1.1.
Propósito: ............................................................ 12
1.2.
Alcance: .............................................................. 12
1.3.
Definiciones, Acrónimos y Abreviaciones: ..................... 13
1.4.
Referencias: ......................................................... 16
1.5.
Visión Global: ....................................................... 17
REPRESENTACIÓN ARQUITECTÓNICA ............................................................................. 17
2.1.
Descripción de la Arquitectura:.................................. 18
2.1.1. Vista Lógica.......................................................... 18
2.1.2. Vista de Procesos ................................................... 18
2.1.3. Vista de desarrollo (implementación) .......................... 18
2.1.4. Vista Física (Despliegue) ......................................... 18
2.1.5. Vista de Escenarios (Casos de Uso)............................. 19
2.1.6. Relación entre las vistas .......................................... 19
3.
OBJETIVOS Y LIMITACIONES ARQUITECTÓNICAS ........................................................... 19
4.
ESTILO ARQUITECTÓNICO ............................................................................................. 20
5.
VISTA DE CASOS DE USO ............................................................................................... 24
5.1.
Ingreso al sistema: ................................................ 24
5.2.
Otorgar Permisos: .................................................. 25
5.3.
Realizar Transferencias ........................................... 27
5.4.
Acceder a Servicios ................................................ 28
5.5.
Generar Servicios .............. Error! Bookmark not defined.
5.6.
Realizar Pago ........................................................ 31
5.7.
Generar Notificaciones ............................................ 32
5.8.
Generación Reportes ............................................... 33
5.9.
Inscripción a Pagos de Servicios Automático ................. 34
5.10.
Generación de Formularios ....................................... 36
5.11.
Eliminación de Servicios ..... Error! Bookmark not defined.
5.12.
Validar Formulario .................................................. 38
5.13.
Verificar Fondos .................................................... 39
5.14.
Salir del Sistema.................................................... 40
5.15.
Creación de Cuenta de Usuario .................................. 41
5.16. Eliminación de Cuenta de Usuario ...... Error! Bookmark not
defined.
6.
VISTA LÓGICA ............................................................................................................... 44
6.1.
Descripción .......................................................... 44
6.2.
Paquetes de diseño importantes para la Arquitectura ...... 45
6.2.1. PRESENTACIÓN ...................................................... 46
6.2.1.1.
PRESENTACIÓN
................................................................................... 46
6.2.1.2.
USUARIOS INTERNOS
........................................................................ 46
6.2.1.3.
USUARIOS EXTERNOS
........................................................................ 46
6.2.2. LÓGICA DE NEGOCIO ............................................... 47
6.2.2.1.
PETICIONES
......................................................................................... 47
6.2.2.2.
TRANSFERENCIA
6.2.2.3.
MODIFICACIÓN
6.2.2.4.
R E P O R T E ................................................................................................
6.2.2.5.
ELIMINACIÓN
6.2.2.6.
CREACIÓN
6.2.2.7.
ENLACES EXTERNOS
................................................................................. 47
................................................................................... 47
47
...................................................................................... 47
............................................................................................. 47
........................................................................... 47
6.2.3. PERSISTENCIA ....................................................... 48
6.2.3.1.
MANEJADOR CONSULTAS
.................................................................. 48
6.2.3.2.
P E R S I S T E N C I A .....................................................................................
48
6.2.4. sistemas heterogéneos ............................................ 49
6.2.4.1.
6.3.
SISTEMAS BANCARIOS
...................................................................... 49
Relaciones con Casos de Uso ..................................... 49
6.3.1
Ingreso al Sistema ....................................... 49
6.3.2
Otorgar Servicios ........................................ 50
6.3.3
Realizar Transferencias ................................. 50
6.3.4
Acceder a Servicios ...................................... 51
6.3.5
Generar Servicios ........................................ 52
6.3.6
Realizar Pagos ............................................ 52
6.3.7
Generar Notificaciones .................................. 53
6.3.8
Generación de Reportes ................................ 53
6.3.9
Inscripción a Pagos de Servicios Automáticos ..... 54
6.3.10
Generación Formularios ................................. 54
6.3.11
defined.
Eliminación de Servicios ....... Error! Bookmark not
6.3.12
Validar Formulario ....................................... 55
6.3.13
Verificar Fondos .......................................... 56
6.3.14
Salir del Sistema ......................................... 56
6.3.15
Creación de Cuenta de Usuario ........................ 57
6.3.16
Eliminación de Cuenta de Usuario .Error! Bookmark
not defined.
7.
VISTA DE PROCESO ....................................................................................................... 58
7.1.
Browser ............................................................... 59
7.2.
Presentación ......................................................... 59
7.3.
Conexión Módulo Browser a Módulo Presentación ............ 60
7.4.
Módulo de Negocio ................................................. 61
7.5.
Conexión Módulo Presentación a Módulo Negocio ............ 62
7.6.
Conexión Módulo Negocio a Módulo j2ee ...................... 63
7.7.
Módulo de Persistencia ............................................ 64
7.8.
Conexión Módulo de Negocio a Módulo de Persistencia ..... 65
7.9.
Módulo de Base de Datos ......................................... 65
7.10.
Conexión Módulo de Persistencia a Módulo de Base de Datos
66
8.
V I S T A D E D E S P L I E G U E ...................................................................................... 67
8.1.
Dispositivos de Acceso ............................................ 68
8.2.
Fachada ............................................................... 68
8.3.
Comunicación Con Los Clientes .................................. 69
8.4.
Intranet GUI ......................................................... 69
8.5.
Manejador De Peticiones .......................................... 70
8.6.
Administrador De Servicios ....................................... 70
8.7.
Servidor De Aplicación ............................................ 71
8.8.
Administrador De Consultas ...................................... 71
8.9.
Otros .................................................................. 72
9.
VISTA DE IMPLEMENTACIÓN .......................................................................................... 72
9.1.
9.1.1
descripción general de la vista de implementación .......... 72
74
9.1.2 lógica del negocio ................................................. 75
9.1.3
persistencia ........................................................ 76
10.
VISTA DE DATOS ........................................................................................................... 77
11.
TAMAÑO Y RENDIMIENTO .............................................................................................. 77
12.
CALIDAD ....................................................................................................................... 77
ÍNDICE DE TABLAS
Tabla 1: Definiciones, acrónimos y abrevaciones ..................................................................................... 15
Tabla 2: Estilo arquitectónico ....................................................................................................................... 22
Tabla 4: CU01 (Ingreso al sistema) ............................................................................................................ 25
Tabla 5: CU02 (Otorgar permisos) .............................................................................................................. 26
Tabla 6: CU03 (Realizar transferencia) ....................................................................................................... 28
Tabla 7: CU04 (Acceder a servicios) ........................................................................................................... 29
Tabla 8: CU05 (Generar servicios) .............................................................................................................. 30
Tabla 9: CU06 (Realizar pago) ..................................................................................................................... 32
Tabla 10: CU07 (Generar notificaciones) ................................................................................................... 33
Tabla 11: CU08 (Generación de reportes) ................................................................................................. 34
Tabla 12: CU09 (Insrcipción a pago de servicios automático) ................................................................ 36
Tabla 13: CU10 (Generación de formularios) ............................................................................................ 37
Tabla 14: CU11 (Eliminación de servicios) ................................................................................................. 38
Tabla 15: CU12 (Validar formulario) ........................................................................................................... 39
Tabla 16: CU13 (Verificar fondos) ............................................................................................................... 40
Tabla 17: CU14 (Salir del sistema) .............................................................................................................. 41
Tabla 18: CU15 (Creación de c u e n t a d e u s u a r i o ) .......................................................................... 42
Tabla 19: CU16 (Eliminación de cuenta de usuario) ................................................................................. 44
ÍNDICE DE ILUSTRACIONES
Ilustración 1: Arquitectura ............................................................................................................................ 23
Ilustración 2: Diagrama de casos de uso ................................................................................................... 24
Ilustración 3: Vista lógica .............................................................................................................................. 45
Ilustración 4: Presentación (Vista lógica) ................................................................................................... 46
Ilustración 5: Lógica del negocio (Vista lógica) ......................................................................................... 47
Ilustración 6: Persistencia (Vista lógica) ..................................................................................................... 48
Ilustración 7: Sistemas heterogéneos (Vista lógica) ................................................................................. 49
Ilustración 8: Diagrama de secuencia de ingreso al sistema .................................................................. 50
Ilustración 9: Diagrama de secuencia de otorgar servicios .................................................................... 50
Ilustración 10: Diagrama de secuencia de realizar transferencias ........................................................ 50
Ilustración 11: Diagrama de secuencia de acceder a servicios .............................................................. 51
Ilustración 12: Diagrama de secuencia de generar servicios .................................................................. 52
Ilustración 13: Diagrama de secuencia de realizar pagos ...................................................................... 52
Ilustración 14: Diagrama de secuencia de generar notificaciones ........................................................ 53
Ilustración 15: Diagrama de secuencia de generación de reportes ....................................................... 54
Ilustración 16: Diagrama de secuencia de inscripción a pagos de servicios
automáticos .............. 54
Ilustración 17: Diagrama de secuencia de generación de formularios ................................................. 54
Ilustración 18: Diagrama de secuencia de eliminación de servicios ..................................................... 55
Ilustración 19: Diagrama de secuencia de validar formulario ................................................................. 55
Ilustración 20: Diagrama de secuencia ....................................................................................................... 56
Ilustración 21: Diagrama de secuencia de salir del sistema .................................................................... 56
Ilustración 22: Diagrama de secuencia de creación de cuenta de usuario ........................................... 57
Ilustración 23: Diagrama de secuencia de eliminación de cuenta de usuario ...................................... 57
Ilustración 24: Vista de proceso .................................................................................................................. 58
Ilustración 25: Browser (Vista de proceso) ................................................................................................ 59
Ilustración 26: Presentación (Vista de proceso) ........................................................................................ 59
Ilustración 27: Conexión módulo browser a módulo presentación (Vista de proceso)........................ 60
Ilustración 28: módulo de negocio (Vista de proceso) ............................................................................. 61
Ilustración 29: Conexión módulo presentación a módulo negocio (Vista de proceso) ........................ 62
Ilustración 30: Conexión módulo negocio a módulo J2EE ....................................................................... 63
Ilustración 31: Módulo persistencia (Vista de proceso) ............................................................................ 64
Ilustración 32: Conexión módulo de negocio a módulo de persistencia (Vista de proceso) ............... 65
Ilustración 33: Módulo de base de datos (Vista de proceso) .................................................................. 65
Ilustración 34: Conexión módulo de persistencia a módulo de base de datos (Vista de proceso) .... 66
Ilustración 35: Vista de despliegue ............................................................................................................. 67
Ilustración 36: Dispositivos de acceso ........................................................................................................ 68
Ilustración 37: Fachada ................................................................................................................................. 68
Ilustración 38: Comunicación con los clientes ........................................................................................... 69
Ilustración 39: Intrantet GUI ........................................................................................................................ 69
Ilustración 40: Manejador de peticiones ..................................................................................................... 70
Ilustración 41: Administrador de servicios ................................................................................................. 70
Ilustración 42: Servidor de aplicación ......................................................................................................... 71
Ilustración 43: Administrador de consultas ................................................................................................ 71
Ilustración 44: Sistemas heterogéneos ....................................................................................................... 72
Ilustración 45: Vista de implementación .................................................................................................... 72
Ilustración 46: Descripción general ............................................................................................................. 73
Ilustración 47: Presentación ](Vista de implementación) ........................................................................ 74
Ilustración 48: Lógica de negocio (Vista de implementación) ................................................................. 75
Ilustración 49: Persistencia (Vista de implementación)............................................................................ 76
Ilustración 50: Vista de datos ...................................................................................................................... 77
1.
INTRODUCCIÓN
Este documento pretende organizar, precisar y analizar los componentes, las
interacciones, las configuraciones y las limitaciones del sistema a construir. Así
mismo describir la arquitectura de un producto de software con fuerte tendencia
de la reutilización eficaz de los componentes del sistema, la base para los
productos y su gestión. En este documento se localiza la descripción arquitectónica
del sistema K^2M-Enterprise, tomando como base el modelo de 4+1 vistas. El
documento contiene:










Representación arquitectónica a utilizar
Objetivos y limitaciones arquitectónicas
Estilo arquitectónica a usar
Casos de uso
Vista lógica
Vista de proceso
Vista de despliegue
Vista de implementación
Vista de datos
Calidad, tamaño y rendimiento
1.1. P r o p ó s i t o :
Este documento proporciona un amplio panorama de la arquitectura del sistema,
utilizando diferentes puntos de vista arquitectónica (4+1), para representar
diferentes aspectos del sistema. De igual forma este documento intenta transmitir
las decisiones arquitectónicas realizadas en el sistema para solucionar el problema
especifico planteado por la corporación Keops Kefrén y Micerinos permitiendo la
evolución del sistema.
1.2. A l c a n c e :
Con este documento se pretende brindar la representación arquitectónica del
sistema K^2M-Enterprise, desarrollado por SouthWard Solutions. El documento
está delimitado por el modelo de 4+1 vistas y el ambiente arquitectónico del
sistema. El sistema por su parte tiene el objetivo de proporcionar los servicios y
requerimientos propuestos por Keops Kefrén y Micerinos para permitirle migrar a
un habiente web.
1.3. D e f i n i c i o n e s , A c r ó n i m o s y A b r e v i a c i o n e s :
En esta sección se presenta y explica la semántica de los términos tanto técnicos
como aquellos con los que el usuario o cliente no esté familiarizado y sean
necesarios para el completo entendimiento del documento. Por tal motivo se
incluirá una tabla de las palabras organizadas alfabéticamente para facilitar el
entendimiento de este documento.
API
BUS
IEEE
JAVA
JAVADOC
A
API hace referencia al acrónimo de Interfaz de
programación de aplicaciones por sus siglas en inglés
Application Program Interface, la cual se trata de un
conjunto de funciones y procedimientos en ciertas
bibliotecas asociadas a un programa. [10]
B
Subsistema que transfiere datos entre componentes del
ordenador, dentro de un ordenador o entre ordenadores.
C
D
E
F
G
H
I
La IEEE hace referencia al acrónimo del instituto de
ingenieros eléctricos y electrónicos por sus siglas en inglés
(Institute of Electrical and Electronics Engineers), el cual es
una organización sin ánimo de lucro que actualmente lidera
la organización profesional para el adelanto de la
tecnología. [1][2]
J
Es un lenguaje de programación de alto nivel, orientado a
objetos y desarrollado por Sun Microsystems. [12]
Es una herramienta de Java que permite generar la
JAVA2D
JAVA2EE
JUNIT
JVM
JAR
LAN
NETBEANS IDE
N-TIER
ORDENADOR:
documentación en formato HTML de los API utilizados. [13]
Es una API de Java con los métodos y clases relacionada al
manejo de imágenes en dos dimensiones. [11]
Es el acrónimo de las siglas en inglés Java 2 Enterprise
Edition, el cual se trata de un estándar para el desarrollo
de aplicaciones empresariales multicapa diseñada por Sun
Microsystems. [12]
Es un conjunto de librerías utilizadas para la realización de
pruebas en las aplicaciones de Java. [14]
Es el acrónimo de las siglas en inglés de Java Virtual
Machine, el cual se trata de la máquina virtual con la que
trabaja Java para ejecutar e interpretar las instrucciones en
binario que son generadas al compilar una aplicación. [10]
“Archivo de Java” por sus siglas en ingles .Es un tipo de
archivo que permite ejecutar aplicaciones escritas en
lenguaje Java.
K
L
Red de área local [15]
M
N
Se trata de un IDE para el desarrollo de aplicaciones de
alto nivel para los lenguajes de programación de Java y
C++ desarrollado por Sun Microsystems. [16]
Arquitectura cliente-servidor en el que, la presentación, la
solicitud de procesamiento y la gestión de datos son
procesos separados lógicamente.
O
Un ordenador es una máquina programable que responde
a un sistema específico de instrucciones de una manera
bien definida y puede ejecutar una lista de instrucciones
pregrabadas [17]
P
Q
R
STAKEHOLDERS
UML
VISTAS 4+1
WAN
S
Son todas las personas involucradas en el desarrollo del
proyecto que van desde el desarrollador, cliente y usuarios.
[3]
T
U
lenguaje Estándar de modelado en el campo de la
ingeniería de software para fines generales [4]
V
Describir la arquitectura de software de sistemas
intensivos, basados en el uso de múltiples y simultáneos
puntos de vista. [19]
W
Red
de computadoras que cubre una amplia zona
geográfica
X
Y
Z
T ABLA 1: D EFINICIONES ,
ACRÓNIMOS Y ABREVACIONES
1.4. R e f e r e n c i a s :
[1] – IEEE Std 1058 - 1998, Software Project Management Plans, IEEE, 1998.
[2] - IEEE, Computer Society Style Guide, References, IEEE, 2007.
[3] - Sommerville I. Ingeniería de Software. 7th ed., Pearson Educación S.A, 2005.
[4] - Larman C., UML Y PATRONES. Una introducción al análisis y diseño orientado
a objetos y al proceso unificado. 2nd ed., Pearson Educación S.A, 2003.
[5] – Crawford William, Kaplan Jonathan. J2EE Design Patterns. 1st ed., O'reilly &
Associates, 2003.
[6] - Elliotte Harold, Elliotte Rusty Harold. Java Network Programming. 3rd ed.,
O'reilly & Associates, 2004.
[9] – Goetz Brian, Peierls Tim, Bloch Joshua, Bowbeer Joseph, Holmes David, Lea
Doug. Java Concurrency in Practice. 1st ed, Addison Wesley Professional, 2006.
[10]- Sun MicroSystems, "API Specifications", Ago 2008;
http://java.sun.com/reference/api/index.html
[11] - Borland, "Software Architecture Design, Visual UML & Businnes Process
Modeling", Ago 2008; http://www.borland.com/us/products/together/index.html
[12] - Sun Microsystems, "Developer Resources for Java Technology", Ago 2008;
http://java.sun.com/
[13] - Sun Microsystems, "Javadoc Tool Home Page", Ago 2008;
http://java.sun.com/j2se/javadoc/
[14] - JUnit, "Resources for Test Driven Development", Ago 2008;
http://www.junit.org/about
[15] - A.S. Tanembaun, Redes de computadores 4ta edición, Pearson, 2003
[16] - Sun Microsystems, "Welcome to NetBeans", Ago 2008;
http://www.netbeans.org/
[17]: http://www.masadelante.com/faq-ordenador.htm
[18]. http://www.mihogarcountrywide.com/enes/glossary/2.aspx
[19]- JGARZAS “LA ARQUITECTURA DE SOFTWARE: EL MODELO 4+1”,
http://jgarzas.googlepages.com/4mas1
[20]- Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1”
View Model of Software Architecture.
1.5. V i s i ó n G l o b a l :
El presente documento está compuesto por diferentes secciones dirigidas a lectores,
expertos, en primera instancia se encuentra una visión general del documento
dirigida a cualquier constructor del sistema para orientarlo en su lectura.
Posteriormente se encuentra una sección dedicada a la descripción global del
ambiente arquitectónico del producto
dirigido a diseñadores, arquitectos y
desarrolladores. Hasta esta parte del documento, se ha introducido lo que va a
contener en términos generales, así como su propósito y alcance. En las siguientes
secciones la descripción arquitectónica se hará con más detalle y básicamente se
pretende:
 Dar a conocer cómo se va a realizar la representación arquitectónica en el
sistema y de qué forma se puede adaptar a las necesidades de los
Stakeholders.
 Mostrar los objetivos que se tienen en cuenta en el ambiente arquitectónico, así
como las limitaciones con las que hay que restringir el sistema.
 Mostrar el estilo arquitectónico que se va a utilizar en el sistema.
 Determinar cómo se va a adaptar el modelo de 4+1 vistas a la arquitectura
planteada para el sistema.
 Características de tamaño y rendimiento de los programas del sistema.
 Contribución del estilo arquitectónico escogido a los atributos de calidad del
sistema.
2.
REPRESENTACIÓN ARQUITECTÓNICA
El sistema K^2M Enterprise es una aplicación en la cual se pretende aplicar los
conceptos fundamentales de diseño e implementación de una arquitectura de
software. Se desea mediante ella mostrar a los Stakeholders una forma más
eficiente, completa y confiable para realizar sus operaciones bancarias y llevar un
control de sus movimientos financieros en cualquier momento, en el sitio que se
desee y requiriendo solamente una conexión a internet y un programa de acceso
web.
La arquitectura está representada mediante vistas, basadas en el modelo 4+1
vistas que se compone de diagramas UML que definen cada una de sus partes,
diseño, implementación, despliegue, procesos y casos de uso; simbolizados
mediante diagramas de estado, interacción, actividad, despliegue, componentes,
clases, objetos, entre otros.
2.1. D e s c r i p c i ó n d e l a A r q u i t e c t u r a :
A continuación se encuentra una descripción de cada uno de los módulos que
componen el modelo 4+1 Vistas de representación de la arquitectura de software:
2.1.1. V i s t a L ó g i c a
En esta vista se realiza el análisis y especificación de los requerimientos
funcionales. Se descompone el sistema en un conjunto de objetos o clases.
La notación más usada dentro de éste es diagramas de clases, de
interacción y objetos. [20][19]
2.1.2. V i s t a d e P r o c e s o s
En esta vista se tratan algunos requerimientos no funcionales. Se especifica
que hilo de control ejecuta cada operación identificada en las clases
elaboradas en la vista lógica. La notación más usada acá es diagramas de
estado, actividad y otros. [20][19]
2.1.3. V i s t a d e d e s a r r o l l o ( i m p l e m e n t a c i ó n )
Esta vista se enfoca en la organización de los módulos de software en el
desarrollo. El software es representado mediante componentes,
subsistemas, librerías entre otros. Todos estos organizados jerárquicamente
por capas proporcionando interfaces bien definidas desde capas inferiores a
superiores. La notación más utilizada es diagramas de componentes y
paquetes. [20][19]
2.1.4. V i s t a F í s i c a ( D e s p l i e g u e )
La vista física contempla la implantación del software sobre hardware. Se
centra en requerimientos no funcionales como disponibilidad, fiabilidad,
escalabilidad y ejecución. También presenta cómo los procesos, objetos,
etc., corresponden a nodos de proceso: [20][19]



Componentes: nodos de proceso.
Conectores: LAN, WAN, bus, etc.
Contenedores: subsistemas físico
Varias configuraciones físicas son válidas siempre y cuando no afecten la
comunicación ni despliegue entre nodos.
2.1.5. V i s t a d e E s c e n a r i o s ( C a s o s d e U s o )
Esta vista unifica las demás vistas, los escenarios que la componen son
instancias de los casos de uso que representan escenarios del sistema. Así,
desde casos de uso se debe poder realizar la trazabilidad a los componentes
del sistema de software, determinando por ejemplo, qué ordenadores,
clases, componentes, jars o procesos son responsables que el sistema cubra
las funcionalidades requeridas. [20][19]
2.1.6.
Relación entre las vistas
La manera lógica de abordar las vistas comienza en la vista de escenarios,
de donde se parte para desarrollar la vista lógica. Asimismo, a partir de la
vista lógica se pasa a la vista de desarrollo y de procesos. Finalmente, de la
vista de procesos se refina la vista física. Cabe aclarar que no son pasos
estrictos ni rígidos, por lo cual cada una de las vistas puede ser sometida a
post-iteraciones para su refinamiento.
3.
OBJETIVOS Y LIMITACIONES ARQUITECTÓNICAS
Debido a la naturaleza del negocio y las necesidades del sistema planteadas por la
organización Keops Kefrén y Micerinos los requerimientos y restricciones generan un
impacto directo en la arquitectura, estos objetivos son:
 EL sistema debe estar disponible las 24 horas del día y los 7 días de la
semana
 El sistema debe brindar seguridad y protección de la información contenida.
 El sistema debe entregar información coherente una vez es realizada una
consulta.
 Las búsquedas y solicitudes hechas por un usuario deben ser atendidas y
respondidas en no más de 10 segundos.
 Si llegara a suceder un fallo el sistema debe estar en condiciones de
recuperarse en no más de 10 minutos.
 En caso de fallo, el sistema debe garantizar la integridad de los datos de los
usuarios.
 Debido a que se puede acceder al sistema desde cualquier dispositivo con
un navegador web, es necesario que se garantice la seguridad de la
información y transacciones bancarias en el momento de realizarse
mediante tecnologías y protocolos especiales.
 Debido a que una de las prioridades del diseño es la seguridad, el sistema
no debe permitir el acceso de usuarios no autorizados, ni debe permitir
hacer modificaciones a la información de cuenta a usuarios que no tienen
los suficientes permisos.
 El sistema debe identificar y administrar los usuarios otorgando y
denegando permisos a los usuarios dependiendo de su perfil.
 El sistema debe proveer ayuda para el usuario para disminuir el impacto
de inserción del producto.
 El sistema debe poder distinguir los diferentes tipos de usuarios existentes
 El sistema debe poder generar reportes de usuario a aquellos Stakeholders
autorizados para ver este tipo de información.
 El sistema debe brindar información acerca de la importancia de la
protección de la clave de acceso y de qué hacer en caso de pérdida o
posible filtración a personas indebidas
 El sistema debe proporcionar información acerca de las normas y leyes
sobre las cuales rigen algunos servicios que se ofrecen.
 El sistema debe permitir que los usuarios se puedan conectar al sistema
mediante cualquier dispositivo de acceso que tenga instalado un navegador
web.
 El sistema debe poder recuperarse si llega a ocurrir algún fallo de tipo
externo o interno.
 El sistema debe ser acorde con las normas y procesos determinadas por el
banco.
 El sistema debe poder atender solicitudes diferentes de hasta 4000 usuarios
por servidor, es decir hasta 8000 solicitudes simultáneas.
 El sistema debe poder realizar hasta 100 transacciones por segundo.
4.
ESTILO ARQUITECTÓNICO
Como realizar la selección del estilo arquitectónico más apropiado requiere de un
método de análisis con base en los atributos de calidad que se buscan satisfacer, a
continuación se describen los atributos de calidad más relevantes y con mayor
impacto directo en la arquitectura del sistema (Calificado de 1 a 5 siendo 1 el
menor y 5 el mayor impacto).
REQUERIMIENTO
DEFINICIÓN
Seguridad de información
ingresada
El sistema debe proteger la información
ingresada al sistema de cualquier acceso
no permitido
4
El sistema debe poder distinguir los
diferentes tipos de usuarios existentes
2
El sistema debe conocer, validar y
permitir el acceso a los diferentes tipos
de usuarios del sistema
1
Diferenciación de usuarios
Tipos de usuarios
Generación de reportes de
usuario
El sistema debe poder mostrar un
informe con todos los usuarios del
sistema a aquellos usuarios autorizados
VALOR
2
para ver este tipo de información
Restricción de cuenta
El sistema debe restringir la modificación
de los datos mostrados al usuario
4
Ayuda en línea
El sistema debe proveer una ayuda en
línea
como
suplemento
para
la
adaptación de los usuarios
2
Información de seguridad
de la clave de acceso
El sistema debe brindar información
acerca de la importancia de la protección
de la clave de acceso y de qué hacer en
caso de pérdida o posible filtración a
personas indebidas
3
Información de normas y
leyes
El sistema debe proporcionar información
acerca de las normas y leyes sobre las
cuales rigen algunos servicios que se
ofrecen
Adaptabilidad a
dispositivos de acceso
Disponibilidad de acceso
Tolerancia a fallos
Tiempo de recuperación
Exactitud
Seguridad del sistema
Capacidad de
El sistema debe permitir que los usuarios
se puedan conectar al sistema mediante
cualquier dispositivo de acceso que tenga
instalado un navegador web.
El sistema debe estar disponible las 24
horas del día y los 7 días de la semana
El sistema debe poder recuperarse si
llega a ocurrir algún fallo de tipo externo
o interno
El sistema debe poder recuperarse si
llega a ocurrir algún fallo de tipo externo
o interno en un tiempo máximo de 10
minutos
El sistema debe ser acorde con las
normas y procesos determinadas por el
banco
El sistema debe proporcionar seguridad
de la información y confidencialidad de la
misma
El sistema debe poder atender solicitudes
2
5
5
5
5
3
4
5
procesamiento de
solicitudes
Tiempo de respuesta a
solicitudes
Rendimiento del sistema
diferentes de hasta 4000 usuarios por
servidor, es decir hasta 8000 solicitudes
simultáneas.
El sistema debe responder a las
solicitudes con un máximo de tiempo de
10 segundos
El sistema debe poder realizar hasta 100
transacciones por segundo
T ABLA 2: E STILO
5
5
ARQUITECTÓNICO
Al observar los resultados obtenidos, los requerimientos más relevantes son los
referentes a eficiencia, confiabilidad y desempeño del sistema. De acuerdo a esto
y a preferencias del grupo de desarrollo, se consideró que el estilo arquitectónico
por capas o N-TIER sería el más correcto y efectivo, considerando que se busca
eficiencia, además que cumple con los atributos de calidad más importantes del
sistema a desarrollar.
A continuación se puede ver la arquitectura planteada para el desarrollo del
sistema, basada en el estilo arquitectónico por capas o N-TIER:
cmp Component Model
Sistema K^2M-Enterprice.
«facade»
Presentación
«business boundary»
ComunicacionClientes
InternetGui
«business boundary»
ComunicacionPersonal
Mov ilesGui
«facade»
IntranetGui
«use»
TagLibraries
JSPs
«use»
Cabe anotar que el modelo contiene
en cada uno de los paquetes mas de
una capa
.
Servicios
Especiales
«https»
Canal
Interno
«https»
Tanto los servicios especiales como canal
interno utilizan VPN para proteger la
confidencialidad
Canal de
Servicio
«http»
Negocio
«case worker» WebServices
Usuario
«flow»
«case worker»
WebServ ices Usuario
«business control»
Administrador de Serv icios
Estos web services facilitan la
integración con otros sistemas
o otras entidades
Manej ador de Procesos
Herramientas
«stub»
Reglas con Externos
«business worker»
EJB de Trabaj o
SessionBeans
EntityBeans
MessageDriv enBeans
«delegate»
Persistencia
«business entity»
Adminitador de Consultas
Repositorio Cuentas Usuarios
«business entity»
Repositorio de Activ os
I LUSTRACIÓN 1: A RQUITECTURA
Para más información por favor remítase al archive arquitectura.rtf.
5.
VISTA DE CASOS DE USO
A continuación se muestra el diagrama de casos de uso y en los numerales
siguientes se puede encontrar la documentación correspondiente a cada uno de
ellos:
uc Use Case Mo...
Casos de uso de contexto
Ingreso al sistema
Administración de
cuenta de usuario
Administración
de serv icios
Otorgar
Permisos
Usuario Administrador
Valiidar
formulario
Usuario Gerente
Acceder a
serv icios
Otras entidades
bancarias
Generar
Reportes
Usuario
Usuario Caj ero Jefe
Generación de
formularios
Realizar
consignación
Usuario Caj ero
Realizar retiro
Inscripción Pago
Serv icios
Automático
Entidades de serv icios
Realizar
Transferencias
VISA y Mastercard
Verificar fondos
Usuario Final
Generar
notificaciones
Salir del sistema
Realizar Pago
I LUSTRACIÓN 2: D IAGRAMA
5.1.
DE CASOS DE USO
Ingreso al sistema:
PROYECTO
K^2M-Enterprise
FECHA
8 de Abril del 2009
AUTOR
Juan Figueredo
VERSION
1.0.0
ID CASO DE USO
CU01
NOMBRE
IngresoSistema
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite a los usuarios
ingresar al sistema por medio de un
formulario que se le presenta
ACTORES PARTICIPANTES
Usuario
ENTRADAS
Documento de ingreso, contraseña de
acceso
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
Ingreso del usuario al sistema
Existencia del usuario en el sistema, datos
correctamente diligenciados y contraseña
correcta
CONDICION FINAL DE ÉXITO
El usuario ha podido ingresar al sistema
CONDICION FINAL DE FALLO
El usuario no ha podido ingresar al
sistema
FLUJO BASICO DE ÉXITO
NUMERO
2
3
CAMINOS DE
EXCEPCION
ACTOR
NUMERO
El usuario diligencia el
formulario de ingreso
al sistema
El usuario envía el
formulario diligenciado
El sistema muestra un
1
formulario de ingreso al
sistema
El sistema valida los datos
4
ingresados por el usuario
El sistema permite el
5
ingreso al usuario
El sistema no pudo realizar la validación del usuario
El usuario no existe en el sistema
EXTENSIONES
CU10, CU12
REQUERIMIENTOS ASOCIADOS
R1, R3, R4, R5, R6, R7, R17, R18
T ABLA 3: CU01 (I NGRESO
5.2.
SISTEMA
AL SISTEMA )
Otorgar Permisos:
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU02
NOMBRE
VERSION
1.0.0
Otorgar permisos
OBJETIVO EN CONTEXTO (RESUMEN)
8 de Abril del 2009
Este caso de uso permite al sistema
otorgarle al usuario que está intentando
ingresar al sistema los permisos
correspondientes a su perfil de usuario
ACTORES PARTICIPANTES
Automático
ENTRADAS
Documento de ingreso, contraseña de
acceso, perfil de usuario
Ingreso del usuario al sistema con los
permisos determinados por su perfil de
usuario
Existencia del usuario en el sistema, datos
correctamente diligenciados, contraseña
de acceso correcta
CONDICION FINAL DE ÉXITO
El usuario ha podido ingresar al sistema
con los permisos determinados por su
perfil de usuario
CONDICION FINAL DE FALLO
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
El usuario ha ingresado al sistema pero
con los permisos que no pertenecen a su
perfil de usuario
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
NUMERO
3
El sistema puede
1
ingresar al sistema con
los permisos de
correspondientes a su
perfil
2
SISTEMA
El sistema verifica el perfil
de usuario de acuerdo a
los datos diligenciados
El sistema otorga los
permisos al usuario de
acuerdo a su perfil
CAMINOS DE
El sistema no pudo otorgarle los permisos al usuario
EXCEPCION
El usuario no existe en el sistema
EXTENSIONES
CU02
REQUERIMIENTOS ASOCIADOS
R1, R8, R9, R10, R11, R12, R13, R14, R16,
R17, R18
T ABLA 4: CU02 (O TORGAR
PERMISOS )
5.3.
Realizar Transferencias
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU03
NOMBRE
VERSION
1.0.0
RealizarTransferencias
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
8 de Abril del 2009
Este caso de uso permite los usuarios
realizar diferentes tipos de transferencias
Usuario
Monto de transferencia, cuenta origen,
cuenta destino, tipo de transferencia
Mensaje de éxito o fallo de la
transferencia
Existencia de cuenta origen, existencia de
cuenta destino, monto no mayor a fondos
en la cuenta origen
CONDICION FINAL DE ÉXITO
La transacción se realiza
satisfactoriamente y se actualizan los
valores de las cuentas
CONDICION FINAL DE FALLO
La transacción no se puede realizar
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
2
El usuario diligencia el
formulario de
transferencia
NUMERO
1
3
4
SISTEMA
El sistema muestra un
formulario para la
correspondiente
transferencia
El sistema valida que los
datos sean correctos
El sistema verifica que el
monto a pagar no sea
mayor a los fondos de la
cuenta origen
5
El sistema muestra
mensaje de éxito o fracaso
CAMINOS DE
El sistema no pudo realizar la transferencia por problemas con
EXCEPCION
cuentas bancarias externas
El cuenta destino no existe en el sistema
EXTENSIONES
CU01, CU02, CU10, CU12
REQUERIMIENTOS ASOCIADOS
R41, R55, R62, R75, R76, R77, R78, R79,
R80, R86, R91, R97
T ABLA 5: CU03 (R EALIZAR
5.4.
TRANSFERENCIA )
Acceder a Servicios
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU04
NOMBRE
VERSION
1.0.0
AccederServicios
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
8 de Abril del 2009
Este caso de uso permite el acceso de a
los servicios que provee el sistema a los
usuarios
Automático
Permisos otorgados y servicios que tiene
el usuario
Acceso a los servicios propios del usuario
Existencia del usuario, el usuario ha
ingresado al sistema.
CONDICION FINAL DE ÉXITO
El usuario puede hacer uso de los
servicios que tiene en el sistema
CONDICION FINAL DE FALLO
El usuario no puede acceder a sus
servicios en el sistema
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
2
El usuario accede a
uno de los servicios
NUMERO
1
SISTEMA
El sistema verifica los
servicios a los que puede
que su perfil le
permite
4
El usuario hace uso del
servicio escogido
3
acceder el usuario de
acuerdo a su perfil de
usuario
El sistema muestra al
usuario los ambientes
correspondientes al
servicio que escogió
CAMINOS DE
El cliente no ha ingresado al sistema
EXCEPCION
EXTENSIONES
CU01, CU02
REQUERIMIENTOS ASOCIADOS
R9, R10, R12, R13, R14, R19, R20, R21,
R22, R40, R51, R54, R56, R60, R68, R69,
R70, R71, R72, R73, R74, R75, R81, R102
T ABLA 6: CU04 (A CCEDER
5.5.
A SERVICIOS )
Administrar servicios
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU05
NOMBRE
VERSION
1.0.0
AdministrarServicios
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
8 de Abril del 2009
Este caso de uso permite que el usuario
administrador genere, elimine o modifique
determinado servicio a un usuario que ya
ha solicitado el nuevo ingreso del mismo
Usuario administrador
Servicio a generar, eliminar o modificar,
usuario a quien se le va a generar,
eliminar o modificar el servicio, datos
adicionales dependiendo del tipo de
servicio
Generación, eliminación o modificación
del servicio de la cuenta de usuario
correspondiente
Existencia del usuario, el usuario
administrador ha ingresado al sistema,
POST-CONDICIONES
validación del banco para adquisición de
nuevo servicio para el usuario o existencia
del servicio para la modificación o
eliminación del mismo.
CONDICION FINAL DE ÉXITO
El servicio ha sido creado, eliminado o
modificado
CONDICION FINAL DE FALLO
El servicio no se ha podido crear, eliminar
o modificar
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
2
El usuario
administrador
diligencia el formulario
5
NUMERO
1
Se le notifica al
usuario de lo que haya
sucedido
con
el
servicio
3
4
SISTEMA
El sistema muestra el
formulario
correspondiente,
dependiendo del que se
quiera ingresar
El sistema valida los datos
ingresados por el usuario
administrador
El sistema realiza la
creación, eliminación o
modificación del servicio
CAMINOS DE
El usuario no ha ingresado al sistema
EXCEPCION
EXTENSIONES
CU01, CU02, CU04, CU10, CU12
REQUERIMIENTOS ASOCIADOS
R9, R10, R12, R13, R14, R15, R19, R20,
R21, R28, R29, R30, R31, R32, R34, R35,
R36, R37, R38, R39, R40, R45, R46, R47,
R48, R49, R68, R69, R70, R81
T ABLA 7: CU05 (A DMINISTRAR
SERVICIOS )
5.6.
Realizar Pago
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU06
NOMBRE
VERSION
1.0.0
RealizarPago
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
8 de Abril del 2009
Este caso de uso permite que los usuarios
puedan realizar diferentes tipos de
transacciones
Usuario
Monto a pagar, cuenta origen, tipo de
pago, información correspondiente a la
transacción a realizar
Mensaje de éxito o fracaso del pago
El usuario ha ingresado al sistema,
existencia de la cuenta origen, validación
de cuenta de origen y validación de la
información correspondiente a la
transacción.
CONDICION FINAL DE ÉXITO
El pago se pudo realizar
satisfactoriamente y se actualiza el valor
de la cuenta y se hace un informe del
pago a la entidad o persona a la que se le
hizo el pago
CONDICION FINAL DE FALLO
El pago no se puede realizar
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
1
El usuario escoge el
tipo de pago que
quiere realizar
NUMERO
2
SISTEMA
El sistema muestra el
formulario de pagos
correspondiente al tipo de
pago que el usuario quiere
realizar
4
El usuario diligencia el
formulario de pagos
El sistema muestra el
formulario de pagos
correspondiente
5
El sistema hace la
validación y verificación de
datos
6
El sistema muestra
mensaje de éxito o fracaso
CAMINOS DE
La cuenta especificada no cuenta con suficientes fondos para la
EXCEPCION
realización del pago
EXTENSIONES
CU01, CU10, CU12
REQUERIMIENTOS ASOCIADOS
R40, R50, R51, R53, R54, R56, R92, R93,
R94, R95
T ABLA 8: CU06 (R EALIZAR
5.7.
3
PAGO )
Generar Notificaciones
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU07
NOMBRE
VERSION
1.0.0
GenerarNotificaciones
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
8 de Abril del 2009
Este caso de uso permite que el sistema
genere notificaciones de las transferencias
y pagos realizados por los usuarios
Automático
Estado de transferencia o pago, cuenta de
usuario
Notificación vía correo electrónico al
usuario del estado de su transferencia o
pago o directamente en pantalla
Existencia de usuario, el usuario ha
intentado realizar una transacción o pago,
existencia de cuenta de correo
electrónico.
CONDICION FINAL DE ÉXITO
El usuario puede ver en su correo
electrónico o en pantalla el estado de su
transacción o pago
CONDICION FINAL DE FALLO
No se le puede notificar al usuario del
estado de su pago o transferencia
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
NUMERO
1
2
3
CAMINOS DE
EXCEPCION
EXTENSIONES
CU03, CU06
REQUERIMIENTOS ASOCIADOS
R87, R89
T ABLA 9: CU07 (G ENERAR
5.8.
SISTEMA
El sistema valida la
transacción o pago
El sistema verifica el
estado de la transacción o
pago
El sistema envía al correo
electrónico o muestra en
pantalla al usuario el
estado de la transferencia
o pago
NOTIFICACIONES )
Generación Reportes
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU08
NOMBRE
VERSION
1.0.0
GeneraciónReportes
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
8 de Abril del 2009
Este caso de uso permite que el sistema
genere reportes automáticamente de
cada uno de los servicios o de todos los
que un usuario necesite acceder
Usuario
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
Estado de servicio deseado, cuenta de
usuario
Reporte en pantalla del estado del
servicio solicitado
Existencia de usuario, permisos
necesarios para que el usuario acceda al
servicio, el usuario debe haber ingresado
al sistema
CONDICION FINAL DE ÉXITO
El usuario puede ver en pantalla el
reporte de estado del servicio solicitado
CONDICION FINAL DE FALLO
El reporte del servicio deseado no se
genera
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
NUMERO
1
El usuario selecciona
2
el servicio del cual
quiere ver el reporte
4
El usuario ve el
3
reporte que solicitó
CAMINOS DE
EXCEPCION
EXTENSIONES
CU01
REQUERIMIENTOS ASOCIADOS
R15, R81, R82, R83, R84, R85, R86, R87,
R88, R89, R90
T ABLA 10: CU08 (G ENERACIÓN
5.9.
SISTEMA
El sistema genera el
reporte de acuerdo al
servicio seleccionado
El sistema muestra en
pantalla el reporte
generado
DE REPORTES )
Inscripción a Pagos de Servicios A utomático
PROYECTO
K^2M-Enterprise
AUTOR
Juan Figueredo
ID CASO DE USO CU09
NOMBRE
FECHA
8 de Abril del 2009
VERSION
1.0.0
InscripciónPagoServiciosAutomático
OBJETIVO EN CONTEXTO
(RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
Este caso de uso permite que el usuario
pueda inscribirse al pago de servicios
automático
Usuario
Servicios que el usuario desea inscribir para
el pago de servicios automáticos, cuenta de
usuario, información necesaria para la
inscripción de cada uno de los servicios
solicitados
Mensaje de éxito o fracaso de la inscripción
El usuario debe haber ingresado al sistema,
el usuario debe tener acceso a los servicios
solicitador para pago automático, los
servicios solicitados deben existir en el
sistema
CONDICION FINAL DE ÉXITO
El usuario ha sido inscrito
satisfactoriamente al pago automático de
servicios
CONDICION FINAL DE FALLO
No se pudo inscribir al usuario al pago
automático de servicios
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
2
El usuario selecciona
los servicios que
quiere que se
realicen a través de
pagos automáticos e
introduce el resto de
datos del formulario
de inscripción
NUMERO
1
3
SISTEMA
El sistema muestra el
formulario de inscripción
de pago de servicios
automático
El sistema valida los
servicios y datos
introducidos por el usuario
4
El sistema realiza los pagos
automáticos de los
servicios escogidos por el
usuario
Falta de fondos para pagos de servicios automáticos
CAMINOS DE
EXCEPCION
EXTENSIONES
CU01, CU10, CU12
REQUERIMIENTOS ASOCIADOS
R51, R56, R88, R89, R101
T ABLA 11: CU09 (I NSRCIPCIÓN
A PAGO DE SERVICIOS AUTOMÁTICO )
5.10. G e n e r a c i ó n d e F o r m u l a r i o s
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU10
NOMBRE
VERSION
1.0.0
GeneraciónFormularios
OBJETIVO EN CONTEXTO (RESUMEN)
8 de Abril del 2009
ACTORES PARTICIPANTES
Este caso de uso permite que el sistema
genere los diferentes formularios que los
usuarios necesitan cuando quieren
acceder a un determinado servicio
Usuario
ENTRADAS
Solicitud de tipo de formulario a generar
SALIDAS
Mostrar en pantalla al usuario el
formulario solicitado
El usuario debe haber ingresado al
sistema, el usuario debe tener acceso a
los servicios solicitador para pago
automático, los servicios solicitados deben
existir en el sistema
CONDICION FINAL DE ÉXITO
El sistema muestra en pantalla el
formulario que el usuario solicitó
CONDICION FINAL DE FALLO
PRE-CONDICIONES
POST-CONDICIONES
No se puede mostrar el formulario
solicitado
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
1
El usuario selecciona
un servicio que
requiere el
diligenciamiento de un
formulario
NUMERO
2
3
SISTEMA
El sistema genera el
formulario dependiendo de
lo que haya seleccionado
el usuario
El sistema muestra en
pantalla el formulario
solicitado
CAMINOS DE
Formulario no disponible
EXCEPCION
EXTENSIONES
CU01, CU10, CU12
REQUERIMIENTOS ASOCIADOS
R6, R23, R24, R25, R26, R33, R34, R35,
R36, R37, R38, R39, R40, R41, R96, R97,
R98, R99, R100
T ABLA 12: CU10 (G ENERACIÓN
DE FORMULA RIOS )
5.11. R e a l i z a r r e t i r o
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU11
NOMBRE
VERSION
1.0.0
RealizarRetiro
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
8 de Abril del 2009
Este caso de uso permite que el usuario
cajero o cajero en jefe realice un retiro de
una cuenta de un usuario si este lo desea,
y permite que los usuarios finales a través
de cajeros electrónicos realicen retiros
Usuario cajero, cajero en jefe, usuario
final
Cuenta de usuario, información del de la
cuenta, monto del retiro
Mensaje de éxito o fracaso de retiro
PRE-CONDICIONES
El usuario cajero o cajero en jefe debe
haber ingresado al sistema o el usuario
final debe haber ingresado al sistema
mediante el cajero electrónico, el monto a
retirar no debe ser mayor que el monto
total de la cuenta a retirar.
CONDICION FINAL DE ÉXITO
Se realiza el retiro
CONDICION FINAL DE FALLO
POST-CONDICIONES
No se puede realizar el retiro
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
2
El usuario
correspondiente llena
el formulario de retiro
NUMERO
1
SISTEMA
Se muestra el formulario
de retiro
3
Validación de formulario de
retiro
4
Se realiza retiro y se
actualiza la
correspondiente cuenta
La cuenta no tiene suficientes fondos para el retiro
CAMINOS DE
EXCEPCION
EXTENSIONES
CU01
REQUERIMIENTOS ASOCIADOS
R42, R103, R104, R105
T ABLA 13: CU11 (R EALIZAR
RETIRO )
5.12. V a l i d a r F o r m u l a r i o
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU12
NOMBRE
VERSION
1.0.0
ValidarFormulario
OBJETIVO EN CONTEXTO (RESUMEN)
8 de Abril del 2009
Este caso de uso permite que el sistema
haga la validación de distintos formularios
ACTORES PARTICIPANTES
Automático
ENTRADAS
Formulario diligenciado
SALIDAS
Formularios validados
PRE-CONDICIONES
El usuario ha diligenciado el formulario
CONDICION FINAL DE ÉXITO
Se valida el formulario
CONDICION FINAL DE FALLO
POST-CONDICIONES
No se puede validar el formulario y se le
presenta un error en el sistema
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
CAMINOS DE
EXCEPCION
EXTENSIONES
CU10
REQUERIMIENTOS ASOCIADOS
NUMERO
1
SISTEMA
Validación de formulario
R24, R25, R26, R39, R40, R41, R50, R51,
R52, R53, R54, R55, R56, R57, R58, R59,
R61, R66, R67
T ABLA 14: CU12 (V ALIDAR
FORMULARIO )
5.13. V e r i f i c a r F o n d o s
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU13
NOMBRE
VERSION
1.0.0
VerificarFondos
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
8 de Abril del 2009
Este caso de uso permite que el sistema
pueda verificar los fondos de una cuenta
para la realización de transferencias y
pagos
Automático
Formulario diligenciado, cuenta origen,
monto a pagar
SALIDAS
Fondos verificados
PRE-CONDICIONES
El usuario ha diligenciado el formulario
CONDICION FINAL DE ÉXITO
Se verifican los fondos de la cuenta de
origen y se comparan con el monto a
pagar
CONDICION FINAL DE FALLO
POST-CONDICIONES
No se pueden verificar los fondos de la
cuenta de origen
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
CAMINOS DE
EXCEPCION
EXTENSIONES
CU03, CU6
REQUERIMIENTOS ASOCIADOS
NUMERO
1
SISTEMA
El sistema verifica que los
fondos de la cuenta son
mayores al monto a pagar
R50, R60, R62, R63, R64, R65
T ABLA 15: CU13 (V ERIFICAR
FONDOS )
5.14. S a l i r d e l S i s t e m a
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU14
NOMBRE
VERSION
1.0.0
SalirDelSistema
OBJETIVO EN CONTEXTO (RESUMEN)
8 de Abril del 2009
ACTORES PARTICIPANTES
Este caso de uso permite que el usuario
salga del sistema
Usuario
ENTRADAS
Solicitud de salida del sistema
SALIDAS
Salida satisfactoria del usuario del sistema
PRE-CONDICIONES
El usuario debe haber ingresado al
sistema
CONDICION FINAL DE ÉXITO
POST-CONDICIONES
El usuario puede salir del sistema
CONDICION FINAL DE FALLO
El usuario no puede salir del sistema
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
1
El usuario solicita salir
del sistema
CAMINOS DE
EXCEPCION
EXTENSIONES
CU01
REQUERIMIENTOS ASOCIADOS
NUMERO
2
SISTEMA
El sistema permite que el
usuario salga del sistema y
guarda los datos
correspondientes
R2
T ABLA 16: CU14 (S ALIR
DEL SISTEMA )
5.15. A d m i n i s t r a c i ó n d e C u e n t a d e U s u a r i o
PROYECTO
K^2M-Enterprise
FECHA
AUTOR
ID CASO DE USO
Juan Figueredo
CU15
NOMBRE
VERSION
1.0.0
CreaciónCuentaUsuario
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
8 de Abril del 2009
Este caso de uso permite que el usuario
administrador pueda crear, eliminar o
modificar una cuenta de usuario en el
sistema
Usuario administrador
Información del nuevo usuario,
información adicional para creación,
eliminación o modificación de cuenta de
usuario
Mensaje de éxito o fracaso de creación,
eliminación o modificación de cuenta de
usuario
PRE-CONDICIONES
El usuario administrador debe haber
ingresado al sistema, si se va a crear una
nueva cuenta de usuario no debe existir
en el sistema, si se va a eliminar o
modificar debe existir en el sistema
CONDICION FINAL DE ÉXITO
Se crea, elimina o modifica la cuenta de
usuario
CONDICION FINAL DE FALLO
POST-CONDICIONES
No se puede crear, eliminar o modificar la
cuenta de usuario
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
2
El usuario
administrador
diligencia el formulario
NUMERO
1
SISTEMA
El sistema muestra el
formulario para la
creación, eliminación o
modificación de cuenta,
dependiendo de lo que se
quiera hacer
El sistema realiza la
validación del formulario
El sistema crea, elimina o
modifica la cuenta de
usuario en el sistema
El sistema muestra
mensaje de éxito
3
4
5
CAMINOS DE
EXCEPCION
EXTENSIONES
CU10, CU12
REQUERIMIENTOS ASOCIADOS
R27, R23, R33, R44
T ABLA 17: CU15 (A DMINISTRACIÓN
DE
cuenta de usuario)
5.16. R e a l i z a r c o n s i g n a c i ó n
PROYECTO
K^2M-Enterprise
FECHA
8 de Abril del 2009
AUTOR
ID CASO DE USO
Juan Figueredo
CU16
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
ACTORES PARTICIPANTES
ENTRADAS
SALIDAS
PRE-CONDICIONES
POST-CONDICIONES
VERSION
1.0.0
RealizarConsignación
Este caso de uso permite que el usuario
cajero o cajero en jefe realice una
consignación a una cuenta de un usuario
del banco cuando un cliente lo desee
Usuario cajero, cajero en jefe
Información de cuenta a la que se va a
realizar la consignación, monto de
consignación
Mensaje de éxito o fracaso de la
consignación
El usuario cajero o cajero en jefe debe
haber ingresado al sistema, la cuenta de a
la que se le va a hacer la consignación
debe existir en el sistema
CONDICION FINAL DE ÉXITO
Se realiza exitosamente la consignación
CONDICION FINAL DE FALLO
No se puede realizar la consignación
FLUJO BASICO DE ÉXITO
NUMERO
ACTOR
NUMERO
2
El usuario cajero o
1
cajero jefe diligencia el
formulario de
consignación
3
CAMINOS DE
SISTEMA
Se le muestra al usuario
cajero o cajero jefe el
formulario de consignación
El sistema valida el
formulario de consignación
4
El sistema realiza la
consignación y actualiza el
monto total de la cuenta
La cuenta de usuario no existe en el sistema
EXCEPCION
EXTENSIONES
CU10, CU12
REQUERIMIENTOS ASOCIADOS
R43, R106,107, 108
T ABLA 18: CU16 (R EALIZAR
6.
CONSIGNACIÓN )
VISTA LÓGICA
Para esta vista se describen los requerimientos funcionales representados como
conjuntos de objetos y relaciones para mostrar el flujo de datos y conexión entre
componentes y paquetes. Su funcionalidad se centra en mostrar, como su nombre
lo dice, la lógica del sistema y el flujo de información dentro de él. A continuación
se describen diferentes capas las cuales se organizan en paquetes, subsistemas y
componentes.
6.1. D e s c r i p c i ó n
La vista lógica del sistema que se muestra a continuación representa un
modelo de n-capas en la que principalmente se observa la presentación, la
lógica de negocio, y la persistencia; sin embargo por lo genérico del modelo,
dentro de estas capas existen otras capas más específicas que se describen
en las siguientes vistas de manera más concreta.
I LUSTRACIÓN 3: V ISTA
LÓGICA
6.2.
Paquetes de diseño importantes para la
Arquitectura
Dentro del diseño arquitectónico se tienen en cuenta los paquetes como
se muestran a continuación:
6.2.1.
PRESENTACIÓN
I LUSTRACIÓN 4: P RESENTACIÓN (V ISTA
6.2.1.1.
LÓGICA )
PRESENTACIÓN
Esta capa interactúa directamente con el usuario y se encarga de recibir los datos
de ingreso del usuario, solicitudes de servicio y validación.
6.2.1.2.
USUARIOS INTERNOS
Este componente formaliza las peticiones de servicios y validaciones de usuario a
nivel interno de la entidad bancaria.
6.2.1.3.
USUARIOS EXTERNOS
Este componente formaliza las peticiones de servicios y validaciones con la
diferencia que se realiza a nivel de usuario final con restricciones y perfiles
específicos (Para mayor información remitirse al diagrama de casos de uso).
6.2.2.
LÓGICA DE NEGOCIO
I LUSTRACIÓN 5: L ÓGICA
6.2.2.1.
DEL NEGOCIO
(V ISTA
LÓGICA )
PETICIONES
Este componente es el encargado de recibir todas las peticiones de usuario y
redireccionarlas al servicio solicitado.
6.2.2.2.
TRANSFERENCIA
Este componente se encarga de manejar la solicitud de transferencia del usuario.
6.2.2.3.
MODIFICACIÓN
Este componente se encarga de manejar las solicitudes de modificación.
6.2.2.4.
REPORTE
Este componente se encarga de manejar las solicitudes de reportes de los
diferentes servicios, estados bancarios, acceso y control de usuarios.
6.2.2.5.
ELIMINACIÓN
Este componente se encarga de manejar las solicitudes de eliminación de
productos, usuarios, transferencias, registros, entre otros.
6.2.2.6.
CREACIÓN
Este componente se encarga de manejar las solicitudes de creación del sistema.
6.2.2.7.
ENLACES EXTERNOS
Este componente se encarga de la comunicación y recepción de información
respecto a entidades heterogéneas externas al sistema.
6.2.3.
PERSISTENCIA
I LUSTRACIÓN 6: P ERSISTENCIA (V ISTA
6.2.3.1.
LÓGICA )
MANEJADOR CONSULTAS
Este componente se encarga de la comunicación y distribución de cargas a la
persistencia y del retorno de respuestas obtenidas de consultas y modificaciones a
la persistencia.
6.2.3.2.
PERSISTENCIA
Cabe anotar que este es un componente externo, sin embargo interactúa
directamente con el paquete de persistencia para el almacenamiento de datos.
6.2.4.
S I S TE M AS HE TE RO G É N E O S
I LUSTRACIÓN 7: S ISTEMAS
6.2.4.1.
HETEROGÉNEOS
(V ISTA
LÓGICA )
SISTEMAS BANCARIOS
Este componente corresponde a todas las entidades bancarias que tienen convenio con
K^2M y que contienen información relevante para los usuarios, como cuentas en
bancos externos, entidades reguladoras, entre otros.
6.3. R e l a c i o n e s c o n C a s o s d e U s o
6.3.1
Ingreso al Sistema
I LUSTRACIÓN 8: D IAGRAMA
6.3.2
Otorgar Servicios
I LUSTRACIÓN 9: D IAGRAMA
6.3.3
DE SECUENCIA DE INGRESO AL SISTEMA
DE SECUENCIA DE OTORGAR SERVICIOS
Realizar Transferencias
I LUSTRACIÓN 10: D IAGRAMA
DE SECUENCIA DE REALIZAR TRANSFERENCIAS
6.3.4
Acceder a Servicios
I LUSTRACIÓN 11: D IAGRAMA
DE SECUENCIA DE ACCEDER A SERVICIOS
6.3.5
Administrar Servicios
I LUSTRACIÓN 12: D IAGRAMA
6.3.6
DE SECUENCIA DE
A DMINISTRAR
SERVICIOS
Realizar Pagos
I LUSTRACIÓN 13: D IAGRAMA
DE SECUENCIA DE REALIZAR PAGOS
6.3.7
Generar Notificaciones
I LUSTRACIÓN 14: D IAGRAMA
6.3.8
DE SECUENCIA DE GENERAR NOTIFICACIONES
Generación de Reportes
I LUSTRACIÓN 15: D IAGRAMA
DE SECUENCIA DE GENERACIÓN DE REPORTES
6.3.9 Inscripción a Pagos de Servicios A utomáticos
I LUSTRACIÓN 16: D IAGRAMA
SERVICIOS
DE SECUENCIA DE INSCRIPCIÓN A PAG OS DE
AUTOMÁTICOS
6.3.10 Generación Formularios
I LUSTRACIÓN 17: D IAGRAMA
DE SECUENCIA DE GENERACIÓN DE FORMULARIOS
6.3.11 Realizar retiro
I LUSTRACIÓN 18: D IAGRAMA
DE SECUENCIA DE REALIZAR RETIRO
6.3.12 Validar Formulario
I LUSTRACIÓN 19: D IAGRAMA
DE SECUENCIA DE VALIDAR FORMULARIO
6.3.13 Verificar Fondos
I LUSTRACIÓN 20: D IAGRAMA
DE SECUENCIA
6.3.14 Salir del Sistema
I LUSTRACIÓN 21: D IAGRAMA
DE SECUENCIA DE SALIR DEL SISTEMA
6.3.15 Administración de Cuenta de Usuario
I LUSTRACIÓN 22: D IAGRAMA
DE SECUENCIA DE
A DMINISTRACIÓN
DE CUENTA
DE USUARIO
6.3.16 Realizar consignación
I LUSTRACIÓN 23: D IAGRAMA
DE SECUENCIA DE REALIZAR CONSIGNACIÓ N
7.
VISTA DE PROCESO
I LUSTRACIÓN 24:
V ISTA DE PROCESO
7.1. B r o w s e r
class Class Mo...
Browser
I LUSTRACIÓN 25: B ROWSER (V ISTA
DE PROCESO )
Este componente es el medio por el cual los usuarios pueden acceder al sistema y de
esta forma realizar diferentes acciones sobre el mismo.
7.2. P r e s e n t a c i ó n
I LUSTRACIÓN 26: P RESENTACIÓN (V ISTA
DE PROCESO )
Este componente se encarga de recibir todas las solicitudes del sistema sin llegar a
procesarlas, simplemente las distribuye dependiendo del tipo de solicitud. Contiene
una sesión, que es a la que entra cada usuario y donde obtiene los permisos
dependiendo del tipo de usuario que es. Tiene un modelo vista controlador, para
separar las responsabilidades antes de acceder al módulo de lógica del negocio. El
controlador se encarga de recibir los datos y enviarlos al modelo para la conexión
con el módulo anteriormente mencionado. Cuando el modelo recibe respuesta de
dicho módulo accede a la vista y ésta se actualiza de tal forma que muestra los
nuevos datos al usuario.
7.3. C o n e x i ó n M ó d u l o B r o w s e r a M ó d u l o P r e s e n t a c i ó n
I LUSTRACIÓN 27: C ONEXIÓN
(V ISTA DE PROCESO )
MÓDULO BROWSER A MÓDULO PRESENTACIÓN
Ésta conexión es de 1 módulo browser a 1 a muchos módulos de presentación,
debido a que cada usuario que entra al browser puede acceder a diferentes tipos
de presentación dependiendo de los permisos que le permite su perfil y a lo que
quiera realizar con el sistema. Asimismo, dependiendo del acceso al que necesite
llegar el usuario la conexión es http, https o vpn, de tal forma dependiendo del
servicio al cuál se esté accediendo se utiliza un diferente tipo, pues hay unas más
seguras que otras.
7.4. M ó d u l o d e N e g o c i o
I LUSTRACIÓN 28:
MÓDULO DE NEGOCIO
(V ISTA
DE PROCESO )
Éste módulo se encarga de realizar todo el procedimiento relacionado con la lógica del
negocio, acá llegan las solicitudes y el administrador de servicios delega los diferentes
servicios dependiendo de la solicitud. Los servicios por su parte se realizan con los
datos recibidos.
7.5. C o n e x i ó n M ó d u l o P r e s e n t a c i ó n a M ó d u l o N e g o c i o
I LUSTRACIÓN 29: C ONEXIÓN
(V ISTA DE PROCESO )
MÓDULO PRESE NTACIÓN A MÓDULO NEGOCIO
La conexión es de un módulo de presentación a muchos módulos de negocio, ya
que se pueden recibir múltiples tipos de solicitudes. La conexión es IIOP ya que es
dentro del mismo sistema que se realiza.
7.6. C o n e x i ó n M ó d u l o N e g o c i o a M ó d u l o j 2 e e
I LUSTRACIÓN 30: C ONEXIÓN
MÓDULO NEGOCIO A MÓDULO
J2EE
El módulo de negocio se conecta al módulo de J2EE, el cual ya tiene definida toda
su conexión interna y sus procedimientos.
7.7. M ó d u l o d e P e r s i s t e n c i a
class Class Mo...
Persistencia
«process»
Administrador de
datos
I LUSTRACIÓN 31: M ÓDULO
PERSISTENCIA
(V ISTA
DE PROCESO )
El módulo de persistencia se encarga de administrar las solicitudes recibidas del
módulo de negocio, de tal forma que delega a los tipos de datos que se solicitan y
los administra para poder manejarlos dependiendo de su tipo.
7.8.
Conexión Módulo de Negocio a Módulo de Persistencia
I LUSTRACIÓN 32: C ONEXIÓN
(V ISTA DE PROCESO )
MÓDULO DE NE GOCIO A MÓDULO DE PE RSISTENCIA
La conexión es de un módulo de negocio a un módulo de persistencia, ya que
todas las solicitudes pasan por un solo módulo de negocio a un solo administrador
de datos.
7.9.
Módulo de Base de Datos
class Class Mo...
Base de datos
I LUSTRACIÓN 33: M ÓDULO
DE BASE DE DATOS
(V ISTA
DE PROCESO )
Este módulo es el encargado de la conexión directa con la base de datos.
7.10. C o n e x i ó n M ó d u l o d e P e r s i s t e n c i a a M ó d u l o d e B a s e d e
Datos
I LUSTRACIÓN 34: C ONEXIÓN
DATOS (V ISTA DE PROCESO )
MÓDULO DE PERSISTENCIA A MÓDULO DE BASE DE
La conexión es de un módulo de administrador de base de datos a un módulo de
base de datos, debido a que un solo administrador se encarga de manejar los
datos y enviar las solicitudes a la base de datos para accederla y consultar los
datos correspondientes
8.
VISTA DE DESPLIEGUE
I LUSTRACIÓN 35: V ISTA
DE DESPLIEGUE
8.1. D i s p o s i t i v o s d e A c c e s o
deployment Deployment Model
«device,Pc»
Computador Personal
«device,HandHeld»
Dispositiv o Móv il
I LUSTRACIÓN 36: D ISPOSITIVOS
«device,Pc»
Terminal del Sistema
DE ACCESO
Estos nodos representan la gran cantidad de dispositivos heterogéneos con
conexión a la red que el sistema está construido para soportar. Particularmente los
computadores personales realizan la conexión al sistema mediante el acceso a
internet con un navegador web o browser tradicional, así mismo los dispositivos de
mano como celulares o pocketpc que posean conexión a internet y un browser
compatible podrán visualizar y utilizar los servicios del sistema. del mismo modo
los terminales del sistema además de poderse conectar al sistema de la misma
forma a los anteriormente mencionados poseen conexión a la intranet del sistema
y funcionalidades extras con aplicaciones pesadas para el uso por parte del
personal de la corporación keops kefrén y micerinos.
8.2. F a c h a d a
deployment Deployment Model
Presentacion
Contenedor UI
«business boundary»
ComunicaciónClientes
InternetGui
Móv ilesGui
JSPs
«business boundary»
ComunicacionPersonal
TagLibraries
IntranetGUI
I LUSTRACIÓN 37: F ACHADA
Esta capa del sistema representa la apariencia externa del sistema, no corresponde a
la totalidad del sistema. Los paquetes en esta capa manejan la presentación para los
múltiples usuarios desde clientes esporádicos hasta personal con uso intensivo de
consultas.
8.3. C o m u n i c a c i ó n C o n L o s C l i e n t e s
deployment Deployment Model
«business boundary»
ComunicaciónClientes
InternetGui
JSPs
Móv ilesGui
I LUSTRACIÓN 38: C OMUNICACIÓN
TagLibraries
CON LOS CLIENTES
Este componente contiene la presentación para aquellos usuarios que aceden al
sistema mediante la internet, así mismo contiene las diferentes configuraciones,
manejadores y tecnologías para representar los servicios web en los diferentes
dispositivos móviles.
8.4. I n t r a n e t G U I
deployment Deployment Model
«business boundary»
ComunicacionPersonal
IntranetGUI
I LUSTRACIÓN 39: I NTRANTET GUI
Este componente contiene la presentación para aquellos usuarios que acceden al
sistema mediante la intranet de la corporación por lo que posee funcionales, permisos
y accesos especiales importantes para la administración del negocio, en consecuencia
otorgando privilegios de acceso y atención.
8.5. M a n e j a d o r D e P e t i c i o n e s
deployment Deployment Model
Manej ador de Peticiones
«business control»
Administrador de Serv icios
Manej ador de Procesos
Herramientas
I LUSTRACIÓN 40: M ANEJADOR
DE PETICIONES
Este nodo del sistema administra las peticiones de los usuarios del sistema mediante
diferentes métodos para proporcionar mejor disponibilidad de los servicios.
8.6. A d m i n i s t r a d o r D e S e r v i c i o s
deployment Deployment Model
«business control»
Administrador de Serv icios
Manej ador de Procesos
Herramientas
I LUSTRACIÓN 41: A DMINISTRADOR
DE SERVICIOS
Este componente contiene los métodos y las herramientas para administrar las
peticiones del los servicios, como el distribuidor de carga, encolador de peticiones,
manejador de prioridades de servicio etc.
8.7. S e r v i d o r D e A p l i c a c i ó n
deployment Deployment Model
Serv idor de Aplicación
«stub»
ReglasCon Externos
«business worker»
EJB de Trabaj o
SessionBeans
EntityBeans
«case worker»
WebServ icesUsusarios
MessageDriv enBeans
I LUSTRACIÓN 42: S ERVIDOR
DE APLICACIÓN
Este nodo contiene la lógica funcional desde los servicios web hasta funcionalidades
específicas del negocio y comunicación con otros sistemas diferentes. En esencia este
nodo permite realizar operaciones requeridas y es de vital importancia para Keops
Kefrén y Micerinos.
8.8. A d m i n i s t r a d o r D e C o n s u l t a s
deployment Deployment Model
Administrador de consultas
I LUSTRACIÓN 43: A DMINISTRADOR
DE CONSULTAS
Este nodo contiene el administrador de acceso a las bases de datos del sistema y
proporciona una importante parte del diseño para asegurar la disponibilidad y
confiabilidad y robustez del sistema. EL administrador permite replicar la
información a múltiples servidores, encolar accesos, y administrar la carga de
acceso entre variados servidores. Finalmente permite el uso de manejadores de
bases de datos heterogéneos para permitir la evolución y extensibilidad del
sistema.
8.9. O t r o s
deployment Deployment Model
«system»
SistemasHeterogeneos
I LUSTRACIÓN 44: S ISTEMAS
HETEROGÉNEOS
Este componente representa todas los diferentes sistemas con el que la aplicación
K^2M-Enterprise debe comunicarse como VISA, MASTERCARD, DATACREDITO etc.
9.
VISTA DE IMPLEMENTACIÓN
I LUSTRACIÓN 45: V ISTA
DE IMPLEMENTACIÓN
9.1.
D E S C RI P C IÓ N G E N E R AL D E L A V IS TA D E I M P LE M E N T AC IÓ N
Con base en el patrón arquitectónico MVC, el sistema se compone de 3 capas
principales sin embargo debido a que es pensado con base en un modelo N-Tier,
existen ciertos detalles que se verán a continuación

Presentación: Es la encargada de tomar los dados que el usuario
ingresa al sistema y enviarlos a la lógica. También se encarga de mostrar
al usuario los datos solicitados. Debido a que se busca disponibilidad en


el sistema, esta pensada como un MVC en conjunto con el componente
Administrador de Servicios incluido en la capa de presentación.
Lógica de Negocio: Se encarga de recibir y atender las solicitudes de
los usuarios. Como fue mencionado antes, el componente Administrador
de Servicios dentro de ésta capa, pertenece al modelo MVC y es quien
se encarga de controlar el flujo de ejecución de las solicitudes de los
usuarios hacia las diferentes funcionalidades del sistema. Es la capa
intermedia debido a que tiene interacción tanto con la capa de
presentación como con la persistencia.
Capa de persistencia: Se encarga de manejar los datos en memoria
para realizar las operaciones solicitadas por el usuario. Se encarga de
acceder a la base de datos y controla el flujo hacia ella mediante un
Administrador de consultas.
I LUSTRACIÓN 46: D ESCRIPCIÓN
GENERAL
9.1.1 PRESENTACIÓN
I LUSTRACIÓN 47: P RESENTACIÓN ](V ISTA
DE IMPLEMENTACIÓN )
 Presentación: Este componente se encarga de la comunicación directa
con el cliente. Además se encarga de validar y direccionar a los usuarios
dependiendo de su perfil y permisos.
 Clientes: Se encarga de mostrar todos los servicios a los que tiene
acceso el usuario.
 Personal: Como clientes, se encarga de mostrar todas las
funcionalidades a las que tiene acceso.
9.1.2
L Ó G IC A D E L N E G O C I O
I LUSTRACIÓN 48: L ÓGICA
DE NEGOCIO
(V ISTA
DE IMPLEMENTACIÓN )
 Administrador de Servicios: Componente encargado de recibir y
direccionar las solicitudes a los componentes capaces de atender la petición.
 Servicios Externos: Componente encargado de atender las solicitudes de
servicios externos (transacciones con entidades fuera del sistema) .
 Servicios: Componente encargado de atender y realizar las operaciones
solicitadas por el usuario. Cabe anotar que en el diagrama solo se observa
uno para una mejor representación y entendimiento, sin embargo en el
sistema existen diferentes componentes de tipo servicios como generación,
eliminación, creación y consulta.
9.1.3
P E R S IS TE N C I A
I LUSTRACIÓN 49: P ERSISTENCIA (V ISTA


DE IMPLEMENTACIÓN )
Administrador de Consultas: Este componente se encarga de
administrar todas las consultas enviadas desde los componentes de servicios
de la capa de Lógica. Es quien dirige las peticiones al repositorio.
Repositorio: Este componente es la representación dentro del sistema de
la base de datos
10.
VISTA DE DATOS
A continuación se muestra la vista de datos que se va a tomar para el módulo de
persistencia mencionado en las vistas 4+1:
I LUSTRACIÓN 50: V ISTA
11.
DE DATOS
TAMAÑO Y RENDIMIENTO
Para información precisa sobre las características de mayor impacto y relevancia
en la arquitectura, así como limitaciones de desempeñó, revisar los incisos 3 y 4
del presente documento y el inciso 5 del SRS.
12.
CALIDAD
Para información sobre los requerimientos o atributos de calidad remítase al
documento de Visión en los incisos 7 y 8 en los cuales se explican, analizan y
priorizan los requerimientos de calidad de acuerdo a análisis realizados con los
Stakeholders los cuales brindaron un acercamiento a los objetivos principales de
calidad en el desarrollo.