DOCUMENTO DE ARQUITECTURA DE SOFTWARE (SAD

Pontificia Universidad Javeriana
DOCUMENTO
DE
ARQUITECTURA DE
SOFTWARE (SAD)
Presentado por K3
Oscar Montenegro, Eberto Burgos, Jair Andrés Moreno
Historial de Cambios
Versión
Fecha
Descripción
Autores
0.1
07-04-09
Línea base SAD
Oscar Montenegro
0.2
07-04-09
Numeral uno
Oscar Montenegro
Vista de Casos de Uso
Oscar Montenegro,
Eberto Burgos,
0.3
08-04-09
Jair Moreno
0.4
09-04-09
Trazabilidad requerimientos, casos de
uso
Eberto Burgos
0.5
13-04-09
Vista Lógica
Oscar Montenegro,
Jair Moreno
0.52
13-04-09
Vista Lógica
Jair Moreno
0.6
14–04-09
Vista de datos
Eberto Burgos
0.65
15-04-09
Vista Lógica
Jair Moreno
0.69
15-04-09
Vista de Despliegue
Oscar Montenegro
0.72
15-04-09
Vista de Proceso
Jair Moreno
0.8
15-04-09
Vista de Desarrollo
Eberto Burgos
Oscar Montenegro
0.9
1.0
15-04-09
16-04-09
Diagramas de Secuencia
Revisión total del documento y
finalización del mismo
Eberto Burgos
Oscar Montenegro,
Jair Moreno,
Eberto Burgos
Página de firmas
El presente documento es aprobado por las personas referenciadas a continuación:
X
Eberto Burgos
Socio
X
Oscar Montenegro
Socio
X
Jair Andres Moreno
Socio
Tabla de contenido
Historial de Cambios .......................................................................................... 2
Página de firmas ............................................................................................... 3
INTRODUCCIÓN .............................................................................................. 10
Propósito: ...................................................................................................................................... 10
Alcance: 10
Definiciones y acrónimos............................................................................................................... 10
Referencias: ................................................................................................................................... 13
Visión Global: ................................................................................................................................. 15
REPRESENTACIÓN ARQUITECTÓNICA .............................................................. 16
Descripción de la Arquitectura: ..................................................................................................... 16
Vista Lógica
16
Vista de Procesos 17
Vista de desarrollo (implementación) .................................................................... 17
Vista Física (Despliegue) ..................................................................................... 17
Vista de Escenarios (Casos de Uso) ...................................................................... 18
Relación entre las vistas ...................................................................................... 18
OBJETIVOS Y LIMITACIONES ARQUITECTÓNICAS ............................................ 19
ESTILO ARQUITECTÓNICO .............................................................................. 20
VISTA DE CASOS DE USO ................................................................................ 23
Ingreso al sistema: ..........................................................................Error! Bookmark not defined.
Otorgar Permisos: ...........................................................................Error! Bookmark not defined.
Realizar Transferencias .................................................................Error! Bookmark not defined.
Acceder a Servicios ........................................................................Error! Bookmark not defined.
Administrar servicios ......................................................................Error! Bookmark not defined.
Realizar Pago ..................................................................................Error! Bookmark not defined.
Generar Notificaciones...................................................................Error! Bookmark not defined.
Generación Reportes .....................................................................Error! Bookmark not defined.
Inscripción a Pagos de Servicios Automático ............................Error! Bookmark not defined.
Generación de Formularios ...........................................................Error! Bookmark not defined.
Realizar retiro ..................................................................................Error! Bookmark not defined.
Validar Formulario...........................................................................Error! Bookmark not defined.
Verificar Fondos ..............................................................................Error! Bookmark not defined.
Salir del Sistema .............................................................................Error! Bookmark not defined.
Administración de Cuenta de Usuario .........................................Error! Bookmark not defined.
Realizar consignación ....................................................................Error! Bookmark not defined.
VISTA LÓGICA ................................................................................................ 44
Descripción ......................................................................................Error! Bookmark not defined.
Paquetes de diseño importantes para la Arquitectura ..............Error! Bookmark not defined.
1.1.1.
PRESENTACIÓN ...........................................................Error! Bookmark not defined.
1.1.2.
LÓGICA DE NEGOCIO .................................................Error! Bookmark not defined.
1.1.3.
PERSISTENCIA..............................................................Error! Bookmark not defined.
1.1.4.
sistemas heterogéneos .....................................................Error! Bookmark not defined.
Relaciones con Casos de Uso ......................................................Error! Bookmark not defined.
INGRESO AL SISTEMA .............................................. Error! Bookmark not defined.
OTORGAR SERVICIOS .............................................. Error! Bookmark not defined.
REALIZAR TRANSFERENCIAS ..................................... Error! Bookmark not defined.
ACCEDER A SERVICIOS ............................................ Error! Bookmark not defined.
ADMINISTRAR SERVICIOS ......................................... Error! Bookmark not defined.
REALIZAR PAGOS Error! Bookmark not defined.
GENERAR NOTIFICACIONES ...................................... Error! Bookmark not defined.
GENERACIÓN DE REPORTES ..................................... Error! Bookmark not defined.
INSCRIPCIÓN A PAGOS DE SERVICIOS AUTOMÁTICOS .... Error! Bookmark not defined.
GENERACIÓN FORMULARIOS .................................... Error! Bookmark not defined.
REALIZAR RETIRO Error! Bookmark not defined.
VALIDAR FORMULARIO ............................................. Error! Bookmark not defined.
VERIFICAR FONDOS ................................................ Error! Bookmark not defined.
SALIR DEL SISTEMA ................................................. Error! Bookmark not defined.
ADMINISTRACIÓN DE CUENTA DE USUARIO.................. Error! Bookmark not defined.
REALIZAR CONSIGNACIÓN ........................................ Error! Bookmark not defined.
VISTA DE PROCESO ........................................................................................ 44
Browser 61
Presentación ................................................................................................................................ 61
Conexión Módulo Browser a Módulo Presentación .............................................................. 62
Módulo de Negocio ..................................................................................................................... 63
Conexión Módulo Presentación a Módulo Negocio .............................................................. 64
Conexión Módulo Negocio a Módulo j2ee .............................................................................. 65
Módulo de Persistencia.............................................................................................................. 66
Conexión Módulo de Negocio a Módulo de Persistencia ..................................................... 67
Módulo de Base de Datos ......................................................................................................... 67
Conexión Módulo de Persistencia a Módulo de Base de Datos ......................................... 68
VISTA DE DESPLIEGUE ................................................................................. 69
Dispositivos de Acceso .............................................................................................................. 70
Fachada 70
Comunicación Con Los Clientes .............................................................................................. 71
Intranet GUI ................................................................................................................................. 71
Manejador De Peticiones........................................................................................................... 72
Administrador De Servicios ....................................................................................................... 72
Servidor De Aplicación ............................................................................................................... 73
Administrador De Consultas ..................................................................................................... 73
Otros
74
VISTA DE IMPLEMENTACIÓN ........................................................................... 75
descripción general de la vista de implementación ...................................................................... 75
9.1.1
76
9.1.2 lógica del negocio ...................................................................................... 78
9.1.3 persistencia .............................................................................................. 78
VISTA DE DATOS ............................................................................................ 80
TAMAÑO Y RENDIMIENTO ............................................................................... 80
CALIDAD ........................................................................................................ 80
ÍNDICE DE TABLAS
Tabla 1: Definiciones, acrónimos y abrevaciones .................................Error! Bookmark not defined.
Tabla 2: Estilo arquitectónico ............................................................................................................ 21
Tabla 4: CU01 (Ingreso al sistema) .................................................................................................... 24
Tabla 5: CU02 (Otorgar permisos) ..................................................................................................... 26
Tabla 6: CU03 (Realizar transferencia) .............................................................................................. 27
Tabla 7: CU04 (Acceder a servicios) .................................................................................................. 28
Tabla 8: CU05 (Generar servicios) ..................................................................................................... 30
Tabla 9: CU06 (Realizar pago) ........................................................................................................... 31
Tabla 10: CU07 (Generar notificaciones) .......................................................................................... 32
Tabla 11: CU08 (Generación de reportes)......................................................................................... 33
Tabla 12: CU09 (Insrcipción a pago de servicios automático) .......................................................... 35
Tabla 13: CU10 (Generación de formularios) .................................................................................... 36
Tabla 14: CU11 (Eliminación de servicios)......................................................................................... 37
Tabla 15: CU12 (Validar formulario) ................................................................................................. 38
Tabla 16: CU13 (Verificar fondos) ..................................................................................................... 39
Tabla 17: CU14 (Salir del sistema) ..................................................................................................... 40
Tabla 18: CU15 (Creación de cuenta de usuario) ............................................................................. 42
Tabla 19: CU16 (Eliminación de cuenta de usuario) ......................................................................... 43
ÍNDICE DE ILUSTRACIONES
Ilustración 1: Arquitectura ................................................................................................................ 22
Ilustración 2: Diagrama de casos de uso ........................................................................................... 23
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 ................................................... 51
Ilustración 11: Diagrama de secuencia de acceder a servicios ........................................................ 52
Ilustración 12: Diagrama de secuencia de generar servicios ............................................................ 53
Ilustración 13: Diagrama de secuencia de realizar pagos ................................................................ 53
Ilustración 14: Diagrama de secuencia de generar notificaciones ................................................... 54
Ilustración 15: Diagrama de secuencia de generación de reportes .................................................. 55
Ilustración 16: Diagrama de secuencia de inscripción a pagos de servicios automáticos ................ 56
Ilustración 17: Diagrama de secuencia de generación de formularios ............................................ 56
Ilustración 18: Diagrama de secuencia de eliminación de servicios ................................................ 56
Ilustración 19: Diagrama de secuencia de validar formulario........................................................... 57
Ilustración 20: Diagrama de secuencia ............................................................................................. 57
Ilustración 21: Diagrama de secuencia de salir del sistema.............................................................. 58
Ilustración 22: Diagrama de secuencia de creación de cuenta de usuario ....................................... 58
Ilustración 23: Diagrama de secuencia de eliminación de cuenta de usuario .................................. 59
Ilustración 24: Vista de proceso ........................................................................................................ 60
Ilustración 25: Browser (Vista de proceso) ....................................................................................... 61
Ilustración 26: Presentación (Vista de proceso)................................................................................ 61
Ilustración 27: Conexión módulo browser a módulo presentación (Vista de proceso) .................... 62
Ilustración 28: módulo de negocio (Vista de proceso)...................................................................... 63
Ilustración 29: Conexión módulo presentación a módulo negocio (Vista de proceso) .................... 64
Ilustración 30: Conexión módulo negocio a módulo J2EE ................................................................ 65
Ilustración 31: Módulo persistencia (Vista de proceso) .................................................................... 66
Ilustración 32: Conexión módulo de negocio a módulo de persistencia (Vista de proceso) ............ 67
Ilustración 33: Módulo de base de datos (Vista de proceso) ............................................................ 67
Ilustración 34: Conexión módulo de persistencia a módulo de base de datos (Vista de proceso) .. 68
Ilustración 35: Vista de despliegue ................................................................................................... 70
Ilustración 36: Dispositivos de acceso ............................................................................................... 70
Ilustración 37: Fachada ..................................................................................................................... 70
Ilustración 38: Comunicación con los clientes .................................................................................. 71
Ilustración 39: Intrantet GUI ............................................................................................................. 71
Ilustración 40: Manejador de peticiones .......................................................................................... 72
Ilustración 41: Administrador de servicios ........................................................................................ 72
Ilustración 42: Servidor de aplicación ............................................................................................... 73
Ilustración 43: Administrador de consultas ...................................................................................... 73
Ilustración 44: Sistemas heterogéneos ............................................................................................. 74
Ilustración 45: Vista de implementación........................................................................................... 75
Ilustración 46: Descripción general ................................................................................................... 76
Ilustración 47: Presentación ](Vista de implementación) ................................................................. 77
Ilustración 48: Lógica de negocio (Vista de implementación) .......................................................... 78
Ilustración 49: Persistencia (Vista de implementación) .................................................................... 79
Ilustración 50: Vista de datos ............................................................................................................ 80
INTRODUCCIÓN
El objetivo principal de este documento es el de analizar y enunciar los componentes,
interacciones, y limitaciones del sistema Banco. Así mismo se pretende describir la arquitectura
que represente el análisis realizado con anterioridad del modelo de 4+1 vistas repasados en las
sesiones de Arquitectura de Software.
PROPÓSITO:
Este documento proporciona una descripción de la arquitectura del sistema basado en los puntos
de vista arquitectónica (4+1), para representar diferentes aspectos del sistema. Esta descripción
sale como resultado de satisfacer todos los requerimientos pedidos por el cliente y de cumplir con
unos servicios típicos de un sistema bancario para diferentes tipos de clientes.
ALCANCE:
Este documento simplemente se dedica a representar, por medio de descripciones de diferentes
vistas, la arquitectura que se utilizará para implementar el sistema K^2M, es decir que no se
especificarán arquitecturas externas al sistema. Como se especificó anteriormente, el documento
utilizará el modelo de 4+1 vistas para hacer esta descripción cuyos ejes centrales son la las vistas
lógica, de procesos, física, desarrollo y escenario.
DEFINICIONES Y ACRÓNIMOS
Actividad: “Trabajo compuesto por un conjunto de tareas. Incluye una descripción, duración y una
secuencia de las tareas a ejecutar con sus entradas y productos a entregar” [1].
Administrador: Persona o entidad que se encarga de aceptar o eliminar nuevos clientes al sistema
con su respectiva información, asigna más espacio de almacenamiento y administra permisos. [9]
API: Aplication Programming Interface
Backup: Copia de Respaldo o Seguridad. Acción de copiar archivos o datos de forma que estén
disponibles en caso de que un fallo produzca la perdida de los originales. Esta sencilla acción evita
numerosos, y a veces irremediables, problemas si se realiza de forma habitual y periódica. [15]
Browser: Un programa utilizado para ver, descargar, cargar, navegar o acceder a otros
documentos (páginas) en la World Wide Web. Los navegadores pueden basarse en texto, lo que
significa que no mostraran gráficos o imágenes, pero la mayoría se basan en texto y gráficos. Los
navegadores leen "etiquetas" o páginas codificadas (utilizando html, aunque no siempre) que
residen en servidores e interpretar el código en los nosotros vemos cuando descargamos una
página web. Netscape Navigator y Microsoft Internet Explorer son ejemplo de Navegadores web.
Moziila Firefox es un ejemplo más reciente. [16]
Ciclo de vida de software: “Es una representación de todas las actividades, tareas y productos
necesarios para desarrollar un sistema software” [1]
Contraseña: Palabra secreta que junto al nombre de usuario le permiten al usuario iniciar una
nueva sesión en el sistema K2M.
EI: External Inputs o entradas externas. “Es un proceso elemental en cuyo dato cruza la frontera de
afuera hacia adentro. Puede venir de una entrada por pantalla o de otra aplicación y puede
mantener uno o más archivos lógicos o ILF’s”. [11]
EIF: External Interface Files o archivos de interfaces externas. “Un grupo de datos lógicamente
relacionados que es usado por motivos de referencia. Los datos residen fuera de la aplicación y
son mantenidos por otras aplicaciones” [11]
EO: External Outputs o salidas externas. “Un proceso elemental en cuyo dato derivado pasa
atreves de la frontera de adentro hacia fuera. Una salida externa puede actualizar un ILF. Los datos
involucrados en el proceso pueden crear reportes o archivos de salida para otras aplicaciones”
[11]
EQ: External Inquiry o consultas externas. Un proceso elemental con ambos componentes de
adentro y de afuera que resulta en la entrega de uno o más archivos de lógica interna o ILF’s y
archivos de interfaz externa o EIF’s. [5]
Evento: Son procedimientos (SUB) que se ejecutan normalmente cuando el sistema operativo
los provoca, por ejemplo, al hacer click en una ventana o en cualquier objeto de la ventana. [17]
Grupo: Conjunto de documentos almacenados dentro del K2M que guardan una relación entre sí.
[9]
Historial: Corresponde a las actividades dentro del sistema que ha tenido el archivo.
IEEE: Institute of Electrical and Electronic Engineers Inc. “Es una asociación internacional sin ánimo
de lucro” con sede principal en Piscataway, Estados Unidos y con subsedes en más de 150 países
del mundo, con alrededor de 360.000 miembros, entre profesionales, estudiantes de Ingeniería,
diseño, derecho, administración, biología y ciencias afines.” [13]
Integridad: “Estado de corrección y completitud de los datos ingresados en un sistema” [6].
Internet: Red de computadores a nivel mundial. Ofrece distintos servicios, como el envío y
recepción de correo electrónico (e-mail), la posibilidad de ver información en las páginas Web, de
participar en foros de discusión (News), de enviar y recibir ficheros mediante FTP, de charlar en
tiempo real mediante IRC.[18]
ILF: Internal Logical Files o archivos internos lógicos. “Un grupo de datos lógicamente relacionados
que reside dentro de los límites de la aplicación y es mantenido por los EI”. [11]
JDNI: Java Naming and Directory Interface. Servicio estándar de nombrado y directorio en Java.
[19]
JVM: Java Virtual Machine
LAN: Local Area Network
Log: Un archivo diario que informa sobre las conexiones a un servidor. [20]
Metadata: información que describe el contenido, calidad, condición, origen, y otras
características de los datos o de otros elementos de información. [21]
Nombre de usuario: Identificacion que junto a la contraseña permiten que este inicie una nueva
sesión en el sistema. [9]
Rol: Responsabilidades asignadas a un miembro del equipo. [1]
Proceso: Conjunto de actividades que se realizan con el fin de producir un software [6]
Puntos funcionales: “Técnica estructurada para analizar los componentes de un sistema
dividiéndolos en grupos de 5 clases y características generales del sistema”. [11]
RAD: Desarrollo rápido de aplicaciones. “Enfoque orientado a objetos para el desarrollo de
sistemas que incluye un método de desarrollo así como herramientas de software” [12]
Repositorio: Cualquier servidor o dispositivo en que se encuentren almacenados ficheros o
archivos de cualquier índole, los cuales se puedan descargar. [22]
Requerimiento: necesidad documentada sobre el contenido, forma o funcionalidad de un
producto o servicio.
Requerimiento funcional: define el comportamiento interno del software: cálculos, detalles
técnicos, manipulación de datos
Requerimiento no funcional: un requerimiento que especifica criterios que pueden usarse para
juzgar la operación de un sistema en lugar de sus comportamientos específicos
RET: “Record Element Type. Un subgrupo identificable de elementos de datos dentro de un ILF o
un EIF”. [5]
SDD: Software Design Document (Documento de diseño de software) “Documento que describe el
modelo de diseño del sistema” [8]
Software: Producto que se compone del programa más una documentación asociada. [2]
SRS: Software Requirements Specifications (Especificaciones de requerimientos de software)
“Documento que describe el sistema de requerimiento de software” [8]
Stakeholder: “Cualquier persona que se encuentre relacionada con el desarrollo del proyecto de
software y que puede ofrecer información para entender el negocio y tomar decisiones más
sensatas al respecto.” Por ejemplo: Cliente, desarrollador, usuario. [6]
Stokeholder: Persona que cuenta con los recursos económicos para el desarrollo del proyecto. [6]
Tarea: Unidad atómica de trabajo que puede es manejada por un miembro del equipo. Toda tarea
consume recursos, muestra como resultado un producto y depende de ostros productos
realizados por sus respectivas tareas [1]
UML: Unified Modelling Language o Lenguaje de modelado Unificado. “Lenguaje de modelado de
sistemas de software”. [5]
Usuario: Persona o entidad que puede gozar de los servicios del sistema K2M accediendo a éste
con la escritura del login y contraseña. Para tener estos servicios, el usuario debió haber sido
aceptado anteriormente por el administrador. [9]
VAF: Value Adjustment Factor. Es la medida de ajuste basada en 14 categorías, en donde cada una
es calificada cuantitativamente en un rango de 0 a 5 según la influencia en la aplicación: 0 significa
que no influye y 5 que es vital en el proyecto. [11]
WEB: World Wide Web. [12]
REFERENCIAS:
[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
http://java.sun.com/reference/api/index.html
Specifications",
Ago
2008;
[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
http://java.sun.com/
for Java Technology",
Ago 2008;
[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.
VISIÓN GLOBAL:
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.
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.
DESCRIPCIÓN DE LA ARQUITECTURA:
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:
Vista Lógica
Según [19] y [20], esta vista tiene como objetivo modelar el diseño y dar soporte a los
requerimientos funcionales que debe proveer el sistema en términos de servicios de los
usuarios. Esta vista arquitectónica se enfoca a la funcionalidad del sistema, mostrar
abstracciones claves que permitan descomponer el sistema en subsistemas para manejar
su complejidad y detallar cada parte.
Esta vista tiene como stakeholders a los usuarios finales o clientes, cuyo principal interés
es la funcionalidad del sistema, pero también es de gran importancia para los arquitectos
de software que pueden abstraer objetos y clases para modelar mejor la arquitectura del
sistema a un alto nivel.
El estilo que se maneja en esta vista es orientado a objetos, por esta razón la herramienta
de modelado más relevante es el diagrama de clases, donde se pueden expresar
abstracciones claves del sistema y sus relaciones.
Vista de Procesos
Según [19] y [20], esta vista tiene como objetivo representar los requerimientos no
funcionales del sistema, por ejemplo, funcionalidad, usabilidad, mantenibilidad, eficiencia
y portabilidad. Además, especifica que hilo de control ejecuta cada operación identificada
en cada clase identificada en la vista lógica. La vista se centra por tanto en la concurrencia
y distribución de procesos.
La representación de la vista de procesos se puede hacer con diagramas de interacción o
diagramas de actividad que permiten modelar procesos concurrentes y distribuidos y
presentar atributos del sistema como rendimiento, escalabilidad y potencia.
Vista de desarrollo (implementación)
En esta vista, según lo expresan [19] y [20] se representan requerimientos internos del
sistema como facilidad de desarrollo, administración de software, reutilización de código y
las limitaciones técnicas que pueden presentar las tecnologías de desarrollo y sus
herramientas.
Su objetivo es presentar una representación modular del sistema, utilizando el estilo de
capas y con esto facilitar el proceso de desarrollo del software y la administración de sus
configuraciones. Para cumplir con este propósito, se definen subsistemas que pueden ser
desarrollados por uno o muchos desarrollador, sin embargo, cada uno de los subsistemas
es organizado en capas jerárquicas para que facilitar el proceso de integración de
sistemas.
Uno de los mayores beneficios que presta esta vista, es que permite planear cada uno de
los aspectos del proyecto de desarrollo como son: complejidad del sistema, planeación de
actividades de codificación, evaluación de costes, planificación, monitorización del
progreso del proyecto, reutilización, portabilidad, seguridad, entre otros.
El principal diagrama que se utiliza para representar esta vista es el diagrama de
componentes y el diagrama de paquetes, ambos estandarizados bajo UML 2.0.
Vista Física (Despliegue)
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.
Vista de Escenarios (Casos de Uso)
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]
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. [20][19]
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 establecer los parámetros que crea convenientes para poder mantener
seguros los datos de los clientes y del banco, especialmente ante fallos en los servidores.

El sistema debe conectarse vía web

Las búsquedas y solicitudes hechas por un usuario cuentan con un “tiempo de tolerancia”
que no sería superior a los 15 segundos.

El sistema debe conocer, validar y permitir el acceso a los diferentes tipos de usuarios del
sistema

Disponibilidad del sistema equivalente al 99,998% del tiempo y en cualquier dispositivo

El sistema debe garantizar la integridad, disponibilidad y confidencialidad de los datos de
los usuarios bajo todas las circunstancias, especialmente, en los fallos. Vale la pena aclarar
que la disponibilidad jugaría a favor del titular de la cuenta o también a las personas
autorizadas de manera que se eviten accesos por parte de personas sin permiso para
realizar algún tipo de operación sobre una cuenta.

En la calidad de banco que es una entidad que hace transacciones, se deben cumplir con
las condiciones ACID para garantizar que las transacciones van a modificar información
cuando se den las condiciones óptimas, es decir, que los datos estén preparados y que no
hayan fallos en la red.

El sistema debe generar reportes de los movimientos realizados del cliente en caso de que
éste los pida o bien luego de un tiempo determinado (3 meses).

El sistema debe manejar permisos para accesos a las cuentas de los clientes.

El sistema debe poder distinguir los tipos de usuarios existentes.


El sistema debe presentar un mecanismo de modificación y recuperación de claves.
El sistema tiene que aplicar las tasas regidas por el Gobierno Nacional.
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 datos guardados
El sistema debe establecer los parámetros que
crea convenientes para poder mantener seguros
5
los datos de los clientes y del banco,
especialmente ante fallos en los servidores.
Conexión
Tiempo de tolerancia
El sistema debe conectarse vía web
VALOR
5
Las búsquedas y solicitudes hechas por un
usuario cuentan con un “tiempo de tolerancia” 2
que no sería superior a los 15 segundos.
Tipos de usuarios
El sistema debe conocer, validar y permitir el
acceso a los diferentes tipos de usuarios del 1
sistema
Disponibilidad
Disponibilidad del sistema equivalente al
4
99,998% del tiempo y en cualquier dispositivo
El sistema debe garantizar la integridad,
disponibilidad y confidencialidad de los datos de
los usuarios bajo todas las circunstancias,
especialmente, en los fallos. Vale la pena aclarar
Integridad,
disponibilidad,
que la disponibilidad jugaría a favor del titular de 5
confidencialidad
la cuenta o también a las personas autorizadas de
manera que se eviten accesos por parte de
personas sin permiso para realizar algún tipo de
operación sobre una cuenta.
Transacciones
En la calidad de banco que es una entidad que
hace transacciones, se deben cumplir con las 5
condiciones ACID para garantizar que las
transacciones van a modificar información
cuando se den las condiciones óptimas, es decir,
que los datos estén preparados y que no hayan
fallos en la red.
Generación de reportes de El sistema debe generar reportes de los
movimientos realizados del cliente en caso de
usuario
2
que éste los pida o bien luego de un tiempo
determinado (3 meses).
Permisos
El sistema debe manejar permisos para accesos a
4
las cuentas de los clientes.
Ayuda en línea
El sistema debe proveer una ayuda en línea como
2
suplemento para la adaptación de los usuarios
El sistema debe brindar información acerca de la
Información de seguridad de la importancia de la protección de la clave de
3
clave de acceso
acceso y de qué hacer en caso de pérdida o
posible filtración a personas indebidas
Información de normas y leyes
El sistema tiene que aplicar las tasas regidas por
2
el Gobierno Nacional.
Recuperación de claves
El sistema debe presentar un mecanismo de
4
modificación y recuperación de claves.
El sistema debe permitir que los usuarios se
Adaptabilidad a dispositivos de puedan conectar al sistema mediante cualquier
5
acceso
dispositivo de acceso que tenga instalado un
navegador web.
Distinción de clientes
Tiempo de
solicitudes
respuesta
El sistema debe poder distinguir los tipos de
3
usuarios existentes.
a El sistema debe responder a las solicitudes con
3
un tiempo máximo de 15 segundos
TABLA 1: ESTILO ARQUITECTÓNICO
Al observar los requerimientos obtenidos, se puede deducir que el estilo por capas 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:
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
ILUSTRACIÓN 1: ARQUITECTURA
Para más información por favor remítase al archive arquitectura.rtf
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
Inscripción Pago
Serv icios
Automático
Usuario Caj ero
Realizar retiro
Entidades de serv icios
Realizar
Transferencias
VISA y Mastercard
Verificar fondos
Usuario Final
Generar
notificaciones
Salir del sistema
Realizar Pago
ILUSTRACIÓN 2: DIAGRAMA DE CASOS DE USO
Ingreso al sistema:
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU01
IngresoSistema
NOMBRE
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
Ingreso del usuario al sistema
PRE-CONDICIONES
Existencia del usuario en el sistema, datos
correctamente diligenciados y contraseña
correcta
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
El usuario ha podido ingresar al sistema
CONDICIÓN FINAL DE FALLO
El usuario no ha podido ingresar al sistema
FLUJO BÁSICO DE ÉXITO
NUMERO
DESCRIPCIÓN
1
El sistema muestra un
formulario de ingreso al 2
sistema
El
usuario
diligencia
el
formulario de ingreso al sistema
3
El usuario envía el
4
formulario diligenciado
El sistema valida los datos
ingresados por el usuario
5
El sistema permite
ingreso al usuario
CAMINOS
EXCEPCIÓN
NUMERO
DESCRIPCIÓN
el
DE El sistema no pudo realizar la validación del usuario
EXTENSIONES
El usuario no existe en el sistema
CU10, CU12
TABLA 2: CU01 (INGRESO AL SISTEMA)
Otorgar Permisos:
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU02
NOMBRE
Otorgar permisos
OBJETIVO EN CONTEXTO (RESUMEN)
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
SALIDAS
Ingreso del usuario al sistema con los permisos
determinados por su perfil de usuario
PRE-CONDICIONES
Existencia del usuario en el sistema, datos
correctamente diligenciados, contraseña de
acceso correcta
CONDICIÓN FINAL DE ÉXITO
POST-CONDICIONES
El usuario ha podido ingresar al sistema con los
permisos determinados por su perfil de usuario
CONDICIÓN FINAL DE FALLO
El usuario ha ingresado al sistema pero con los
permisos que no pertenecen a su perfil de usuario
FLUJO BASICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El sistema verifica el perfil 2
de usuario de acuerdo a
los datos diligenciados
3
El sistema puede ingresar
al sistema con los permisos
de correspondientes a su
perfil
CAMINOS
EXCEPCION
NÚMERO
DESCRIPCIÓN
El sistema otorga los permisos
al usuario de acuerdo a su perfil
DE El sistema no pudo otorgarle los permisos al usuario
El usuario no existe en el sistema
EXTENSIONES
CU02
TABLA 3: CU02 (OTORGAR PERMISOS)
Realizar Transferencias
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU03
RealizarTransferencias
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite los usuarios realizar
diferentes tipos de transferencias
ACTORES PARTICIPANTES
Usuario
ENTRADAS
Monto de transferencia, cuenta origen, cuenta
destino, tipo de transferencia
SALIDAS
Mensaje de éxito o fallo de la transferencia
PRE-CONDICIONES
Existencia de cuenta origen, existencia de cuenta
destino, monto no mayor a fondos en la cuenta
origen
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
La transacción se realiza satisfactoriamente y se
actualizan los valores de las cuentas
CONDICIÓN FINAL DE FALLO
La transacción no se puede realizar
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
NÚMERO
1
El sistema muestra un 2
formulario
para
la
DESCRIPCIÓN
El
usuario
diligencia
formulario de transferencia
el
correspondiente
transferencia
3
El sistema valida que los 4
datos sean correctos
5
El
sistema
muestra
mensaje de éxito o fracaso
CAMINOS
EXCEPCIÓN
El sistema verifica que el monto
a pagar no sea mayor a los
fondos de la cuenta origen
DE El sistema no pudo realizar la transferencia por problemas con cuentas
bancarias externas
El cuenta destino no existe en el sistema
EXTENSIONES
CU01, CU02, CU10, CU12
TABLA 4: CU03 (REALIZAR TRANSFERENCIA)
Acceder a Servicios
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU04
AccederServicios
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite el acceso de a los
servicios que provee el sistema a los usuarios
ACTORES PARTICIPANTES
Automático
ENTRADAS
Permisos otorgados y servicios que tiene el
usuario
SALIDAS
Acceso a los servicios propios del usuario
PRE-CONDICIONES
Existencia del usuario, el usuario ha ingresado al
sistema.
CONDICIÓN FINAL DE ÉXITO
POST-CONDICIONES
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 BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El sistema verifica los 2
servicios a los que puede
acceder el usuario de
acuerdo a su perfil de
usuario
El usuario accede a uno de los
servicios que su perfil le
permite
3
El sistema muestra al 4
usuario los ambientes
correspondientes
al
servicio que escogió
El usuario hace uso del servicio
escogido
CAMINOS
EXCEPCIÓN
EXTENSIONES
NÚMERO
DESCRIPCIÓN
DE El cliente no ha ingresado al sistema
CU01, CU02
TABLA 5: CU04 (ACCEDER A SERVICIOS)
Administrar servicios
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU05
AdministrarServicios
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
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
ACTORES PARTICIPANTES
Usuario administrador
ENTRADAS
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
SALIDAS
Generación, eliminación o modificación del
servicio de la cuenta de usuario correspondiente
PRE-CONDICIONES
Existencia del usuario, el usuario administrador ha
ingresado al sistema, 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.
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
El servicio ha sido creado, eliminado o modificado
CONDICIÓN FINAL DE FALLO
El servicio no se ha podido crear, eliminar o
modificar
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
NÚMERO
DESCRIPCIÓN
1
El sistema muestra el 2
formulario
correspondiente,
dependiendo del que se
quiera ingresar
El
usuario
administrador
diligencia el formulario
3
El sistema valida los datos 4
ingresados por el usuario
administrador
El sistema realiza la creación,
eliminación o modificación del
servicio
5
Se le notifica al usuario de
lo que haya sucedido con
el servicio
CAMINOS
EXCEPCIÓN
DE El usuario no ha ingresado al sistema
EXTENSIONES
CU01, CU02, CU04, CU10, CU12
TABLA 6: CU05 (ADMINISTRAR
SERVICIOS)
Realizar Pago
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSION
1.0.0
ID CASO DE USO
CU06
RealizarPago
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que los usuarios puedan
realizar diferentes tipos de transacciones
ACTORES PARTICIPANTES
Usuario
ENTRADAS
Monto a pagar, cuenta origen, tipo de pago,
información correspondiente a la transacción a
realizar
SALIDAS
Mensaje de éxito o fracaso del pago
PRE-CONDICIONES
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.
POST-CONDICIONES
CONDICIÓN 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
CONDICIÓN FINAL DE FALLO
El pago no se puede realizar
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El usuario escoge el tipo de 2
pago que quiere realizar
El
sistema
muestra
el
formulario
de
pagos
correspondiente al tipo de pago
que el usuario quiere realizar
3
El sistema muestra el 4
formulario
de
pagos
correspondiente
El
usuario
diligencia
formulario de pagos
5
El
sistema
hace
la 6
validación y verificación de
datos
El sistema muestra mensaje de
éxito o fracaso
CAMINOS
EXCEPCION
EXTENSIONES
NÚMERO
DESCRIPCIÓN
el
DE La cuenta especificada no cuenta con suficientes fondos para la realización
del pago
CU01, CU10, CU12
TABLA 7: CU06 (REALIZAR PAGO)
Generar Notificaciones
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU07
GenerarNotificaciones
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que el sistema genere
notificaciones de las transferencias y pagos
realizados por los usuarios
ACTORES PARTICIPANTES
Automático
ENTRADAS
Estado de transferencia o pago, cuenta de usuario
SALIDAS
Notificación vía correo electrónico al usuario del
estado de su transferencia o pago o directamente
en pantalla
PRE-CONDICIONES
Existencia de usuario, el usuario ha intentado
realizar una transacción o pago, existencia de
cuenta de correo electrónico.
CONDICIÓN FINAL DE ÉXITO
POST-CONDICIONES
El usuario puede ver en su correo electrónico o en
pantalla el estado de su transacción o pago
CONDICIÓN FINAL DE FALLO
No se le puede notificar al usuario del estado de
su pago o transferencia
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El sistema valida
transacción o pago
3
El sistema envía al correo
electrónico o muestra en
pantalla al usuario el
estado de la transferencia
o pago
CAMINOS
EXCEPCIÓN
EXTENSIONES
NÚMERO
la 2
DESCRIPCIÓN
El sistema verifica el estado de
la transacción o pago
DE
CU03, CU06
TABLA 8: CU07 (GENERAR NOTIFICACIONES)
Generación Reportes
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU08
GeneraciónReportes
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
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
ACTORES PARTICIPANTES
Usuario
ENTRADAS
Estado de servicio deseado, cuenta de usuario
SALIDAS
Reporte en pantalla del estado del servicio
solicitado
PRE-CONDICIONES
Existencia de usuario, permisos necesarios para
que el usuario acceda al servicio, el usuario debe
haber ingresado al sistema
POST-CONDICIONES
CONDICIÓN 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 BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El usuario selecciona el 2
servicio del cual quiere ver
el reporte
El sistema genera el reporte de
acuerdo al servicio seleccionado
3
El sistema muestra en 4
pantalla
el
reporte
generado
El usuario ve el reporte que
solicitó
CAMINOS
EXCEPCIÓN
EXTENSIONES
DE
CU01
TABLA 9: CU08 (GENERACIÓN DE REPORTES)
Inscripción a Pagos de Servicios Automático
NÚMERO
DESCRIPCIÓN
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSION
1.0.0
ID CASO DE USO
CU09
InscripciónPagoServiciosAutomático
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que el usuario pueda
inscribirse al pago de servicios automático
ACTORES PARTICIPANTES
Usuario
ENTRADAS
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
SALIDAS
Mensaje de éxito o fracaso de la inscripción
PRE-CONDICIONES
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
CONDICIÓN FINAL DE ÉXITO
POST-CONDICIONES
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 BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
NÚMERO
1
El sistema muestra el 2
formulario de inscripción
de pago de servicios
automático
DESCRIPCIÓN
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
3
CAMINOS
EXCEPCIÓN
El sistema valida los 4
servicios
y
datos
introducidos
por
el
usuario
El sistema realiza los pagos
automáticos de los servicios
escogidos por el usuario
DE Falta de fondos para pagos de servicios automáticos
EXTENSIONES
CU01, CU10, CU12
TABLA 10: CU09 (INSRCIPCIÓN A PAGO DE SERVICIOS AUTOMÁTICO)
Generación de Formularios
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU10
GeneraciónFormularios
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que el sistema genere
los diferentes formularios que los usuarios
necesitan cuando quieren acceder a un
determinado servicio
ACTORES PARTICIPANTES
Usuario
ENTRADAS
Solicitud de tipo de formulario a generar
SALIDAS
Mostrar en pantalla al usuario el formulario
solicitado
PRE-CONDICIONES
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
CONDICIÓN FINAL DE ÉXITO
POST-CONDICIONES
El sistema muestra en pantalla el formulario que
el usuario solicitó
CONDICION FINAL DE FALLO
No se puede mostrar el formulario solicitado
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El usuario selecciona un 2
servicio que requiere el
diligenciamiento de un
formulario
3
El sistema muestra en
pantalla el formulario
solicitado
CAMINOS
EXCEPCIÓN
EXTENSIONES
NÚMERO
DESCRIPCIÓN
El sistema genera el formulario
dependiendo de lo que haya
seleccionado el usuario
DE Formulario no disponible
CU01, CU10, CU12
TABLA 11: CU10 (GENERACIÓN DE FORMULARIOS)
Realizar retiro
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU11
RealizarRetiro
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
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
ACTORES PARTICIPANTES
Usuario cajero, cajero en jefe, usuario final
ENTRADAS
Cuenta de usuario, información del de la cuenta,
monto del retiro
SALIDAS
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.
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
Se realiza el retiro
CONDICIÓN FINAL DE FALLO
No se puede realizar el retiro
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
Se muestra el formulario 2
de retiro
El usuario correspondiente llena
el formulario de retiro
3
Validación de formulario 4
de retiro
Se realiza retiro y se actualiza la
correspondiente cuenta
CAMINOS
EXCEPCIÓN
NÚMERO
DESCRIPCIÓN
DE La cuenta no tiene suficientes fondos para el retiro
EXTENSIONES
CU01
TABLA 12: CU11 (REALIZAR RETIRO)
Validar Formulario
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU12
ValidarFormulario
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
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
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
Se valida el formulario
CONDICIÓN FINAL DE FALLO
No se puede validar el formulario y se le presenta
un error en el sistema
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
Validación de formulario
CAMINOS
EXCEPCIÓN
NÚMERO
DESCRIPCIÓN
DE
EXTENSIONES
CU10
TABLA 13: CU12 (VALIDAR FORMULARIO)
Verificar Fondos
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU13
VerificarFondos
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que el sistema pueda
verificar los fondos de una cuenta para la
realización de transferencias y pagos
ACTORES PARTICIPANTES
Automático
ENTRADAS
Formulario diligenciado, cuenta origen, monto a
pagar
SALIDAS
Fondos verificados
PRE-CONDICIONES
El usuario ha diligenciado el formulario
CONDICIÓN FINAL DE ÉXITO
POST-CONDICIONES
Se verifican los fondos de la cuenta de origen y se
comparan con el monto a pagar
CONDICION FINAL DE FALLO
No se pueden verificar los fondos de la cuenta de
origen
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El sistema verifica que los
fondos de la cuenta son
mayores al monto a pagar
CAMINOS
EXCEPCIÓN
NÚMERO
DESCRIPCIÓN
DE
EXTENSIONES
CU03, CU6
TABLA 14: CU13 (VERIFICAR FONDOS)
Salir del Sistema
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU14
SalirDelSistema
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que el usuario salga del
sistema
ACTORES PARTICIPANTES
Usuario
ENTRADAS
Solicitud de salida del sistema
SALIDAS
Salida satisfactoria del usuario del sistema
PRE-CONDICIONES
El usuario debe haber ingresado al sistema
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
El usuario puede salir del sistema
CONDICIÓN FINAL DE FALLO
El usuario no puede salir del sistema
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
El usuario solicita salir del 2
sistema
CAMINOS
EXCEPCIÓN
EXTENSIONES
NÚMERO
DESCRIPCIÓN
El sistema permite que el
usuario salga del sistema y
guarda
los
datos
correspondientes
DE
CU01
TABLA 15: CU14 (SALIR DEL SISTEMA)
Administración de Cuenta de Usuario
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU15
CreaciónCuentaUsuario
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
Este caso de uso permite que el usuario
administrador pueda crear, eliminar o modificar
una cuenta de usuario en el sistema
ACTORES PARTICIPANTES
Usuario administrador
ENTRADAS
Información del nuevo usuario, información
adicional para creación, eliminación o
modificación de cuenta de usuario
SALIDAS
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
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
Se crea, elimina o modifica la cuenta de usuario
CONDICIÓN FINAL DE FALLO
No se puede crear, eliminar o modificar la cuenta
de usuario
FLUJO BÁSICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
NÚMERO
DESCRIPCIÓN
1
El sistema muestra el 2
formulario
para
la
creación, eliminación o
modificación de cuenta,
dependiendo de lo que se
quiera hacer
El
usuario
administrador
diligencia el formulario
3
El sistema realiza la 4
validación del formulario
El sistema crea, elimina o
modifica la cuenta de usuario
en el sistema
5
CAMINOS
EXCEPCIÓN
El
sistema
muestra
mensaje de éxito
DE
EXTENSIONES
CU10, CU12
TABLA 16: CU15 (ADMINISTRACIÓN
DE
cuenta de usuario)
Realizar consignación
PROYECTO
K^2M
FECHA
8 de Abril del 2009
AUTOR
Eberto Burgos
VERSIÓN
1.0.0
ID CASO DE USO
CU16
RealizarConsignación
NOMBRE
OBJETIVO EN CONTEXTO (RESUMEN)
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
ACTORES PARTICIPANTES
Usuario cajero, cajero en jefe
ENTRADAS
Información de cuenta a la que se va a realizar la
consignación, monto de consignación
SALIDAS
Mensaje de éxito o fracaso de la consignación
PRE-CONDICIONES
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
POST-CONDICIONES
CONDICIÓN FINAL DE ÉXITO
Se realiza exitosamente la consignación
CONDICIÓN FINAL DE FALLO
No se puede realizar la consignación
FLUJO BASICO DE ÉXITO
NÚMERO
DESCRIPCIÓN
1
Se le muestra al usuario 2
cajero o cajero jefe el
formulario de consignación
El usuario cajero o cajero jefe
diligencia el formulario de
consignación
3
El sistema valida el 4
formulario de consignación
El
sistema
realiza
consignación y actualiza
monto total de la cuenta
CAMINOS
EXCEPCIÓN
EXTENSIONES
NÚMERO
DE La cuenta de usuario no existe en el sistema
CU10, CU12
TABLA 17: CU16 (REALIZAR CONSIGNACIÓN)
DESCRIPCIÓN
la
el
VISTA LÓGICA
En esta vista se puede observar los diferentes componentes principales y sus relaciones, además
se tienen en cuenta detalles técnicos y un principio para la implementación de la plataforma
basándose en la lógica del negocio. 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.
DESCRIPCIÓ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.
ILUSTRACIÓN 3: VISTA LÓGICA
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:
PRESENTACIÓN
ILUSTRACIÓN 4: PRESENTACIÓN (VISTA LÓGICA)
P R E S E N T A C IÓ 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.
U S U AR IO S IN TE R N O S
Este componente formaliza las peticiones de servicios y validaciones de usuario a nivel interno de
la entidad bancaria.
U S U AR IO S EX TE R N O S
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).
LÓGICA DE NEGOCIO
ILUSTRACIÓN 5: LÓGICA DEL NEGOCIO (VISTA LÓGICA)
P ET I C IO N E S
Este componente es el encargado de recibir todas las peticiones de usuario y redireccionarlas al
servicio solicitado.
TR AN S F ER EN C I A
Este componente se encarga de manejar la solicitud de transferencia del usuario.
M O D IF I C A C IÓ N
Este componente se encarga de manejar las solicitudes de modificación.
R EP O R TE
Este componente se encarga de manejar las solicitudes de reportes de los diferentes servicios,
estados bancarios, acceso y control de usuarios.
EL I M IN AC I Ó N
Este componente se encarga de manejar las solicitudes de eliminación de productos, usuarios,
transferencias, registros, entre otros.
CR E A C IÓ N
Este componente se encarga de manejar las solicitudes de creación del sistema.
EN LA C E S E X T ER N O S
Este componente se encarga de la comunicación y recepción de información respecto a entidades
heterogéneas externas al sistema.
PERSISTENCIA
ILUSTRACIÓN 6: PERSISTENCIA (VISTA LÓGICA)
M AN EJ AD O R CO N S U L TA S
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.
P ER S IS TEN C I A
Cabe anotar que este es un componente externo, sin embargo interactúa directamente con el
paquete de persistencia para el almacenamiento de datos.
Sistemas heterogéneos
ILUSTRACIÓN 7: SISTEMAS HETEROGÉNEOS (VISTA LÓGICA)
S I S T EM A S B AN CA R IO S
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.
RELACIONES CON CASOS DE USO
Ingreso al Sistema
ILUSTRACIÓN 8: DIAGRAMA DE SECUENCIA DE INGRESO AL SISTEMA
Otorgar Servicios
ILUSTRACIÓN 9: DIAGRAMA DE SECUENCIA
DE OTORGAR SERVICIOS
Realizar Transferencias
ILUSTRACIÓN 10: DIAGRAMA DE SECUENCIA
Acceder a Servicios
DE REALIZAR TRANSFERENCIAS
ILUSTRACIÓN 11: DIAGRAMA DE SECUENCIA
DE ACCEDER A SERVICIOS
Administrar Servicios
ILUSTRACIÓN 12: DIAGRAMA DE SECUENCIA DE ADMINISTRAR SERVICIOS
Realizar Pagos
ILUSTRACIÓN 13: DIAGRAMA DE SECUENCIA
DE REALIZAR PAGOS
Generar Notificaciones
ILUSTRACIÓN 14: DIAGRAMA DE SECUENCIA
DE GENERAR NOTIFICACIONES
Generación de Reportes
ILUSTRACIÓN 15: DIAGRAMA DE SECUENCIA DE GENERACIÓN DE REPORTES
Inscripción a Pagos de Servicios Automáticos
ILUSTRACIÓN 16: DIAGRAMA DE SECUENCIA DE INSCRIPCIÓN A PAGOS DE SERVICIOS AUTOMÁTICOS
Generación Formularios
ILUSTRACIÓN 17: DIAGRAMA DE SECUENCIA
DE GENERACIÓN DE FORMULARIOS
Realizar retiro
ILUSTRACIÓN 18: DIAGRAMA DE SECUENCIA
DE REALIZAR RETIRO
Validar Formulario
ILUSTRACIÓN 19: DIAGRAMA DE SECUENCIA DE VALIDAR FORMULARIO
Verificar Fondos
ILUSTRACIÓN 20: DIAGRAMA DE SECUENCIA
Salir del Sistema
ILUSTRACIÓN 21: DIAGRAMA DE SECUENCIA DE SALIR DEL SISTEMA
Administración de Cuenta de Usuario
ILUSTRACIÓN 22: DIAGRAMA DE SECUENCIA DE ADMINISTRACIÓN DE CUENTA DE USUARIO
Realizar consignación
ILUSTRACIÓN 23: DIAGRAMA DE SECUENCIA DE REALIZAR CONSIGNACIÓN
}
ILUSTRACIÓN
24: VISTA DE PROCESO
VISTA DE PROCESO
BROWSER
class Class Mo...
Browser
ILUSTRACIÓN 25: BROWSER (VISTA 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.
PRESENTACIÓN
ILUSTRACIÓN 26: PRESENTACIÓN (VISTA 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.
CONEXIÓN MÓDULO BROWSER A MÓDULO PRESENTACIÓN
ILUSTRACIÓN 27: CONEXIÓN MÓDULO BROWSER A MÓDULO PRESENTACIÓN (VISTA DE PROCESO)
É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 cual se esté accediendo se utiliza un diferente tipo, pues hay
unas más seguras que otras.
MÓDULO DE NEGOCIO
ILUSTRACIÓN 28: MÓDULO DE NEGOCIO (VISTA DE PROCESO)
Este 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.
CONEXIÓN MÓDULO PRESENTACIÓN A MÓDULO NEGOCIO
ILUSTRACIÓN 29: CONEXIÓN MÓDULO PRESENTACIÓN A MÓDULO NEGOCIO (VISTA DE PROCESO)
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.
CONEXIÓN MÓDULO NEGOCIO A MÓDULO J2EE
ILUSTRACIÓN 30: CONEXIÓ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.
MÓDULO DE PERSISTENCIA
class Class Mo...
Persistencia
«process»
Administrador de
datos
ILUSTRACIÓN 31: MÓDULO PERSISTENCIA (VISTA 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.
Conexión Módulo de Negocio a Módulo de Persistencia
ILUSTRACIÓN 32: CONEXIÓN MÓDULO DE NEGOCIO A MÓDULO DE PERSISTENCIA (VISTA DE PROCESO)
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.
MÓDULO DE BASE DE DATOS
class Class Mo...
Base de datos
ILUSTRACIÓN 33: MÓDULO DE BASE DE DATOS (VISTA DE PROCESO)
Este módulo es el encargado de la conexión directa con la base de datos.
Conexión Módulo de Persistencia a Módulo de Base de Datos
ILUSTRACIÓN 34: CONEXIÓN MÓDULO DE PERSISTENCIA A MÓDULO DE BASE DE DATOS (VISTA DE PROCESO)
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
VISTA DE DESPLIEGUE
ILUSTRACIÓN 35: VISTA DE DESPLIEGUE
DISPOSITIVOS DE ACCESO
deployment Deployment Model
«device,Pc»
Computador Personal
«device,HandHeld»
Dispositiv o Móv il
«device,Pc»
Terminal del Sistema
ILUSTRACIÓN 36: DISPOSITIVOS 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.
FACHADA
deployment Deployment Model
Presentacion
Contenedor UI
«business boundary»
ComunicaciónClientes
InternetGui
Móv ilesGui
JSPs
«business boundary»
ComunicacionPersonal
TagLibraries
IntranetGUI
ILUSTRACIÓN 37: FACHADA
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.
COMUNICACIÓN CON LOS CLIENTES
deployment Deployment Model
«business boundary»
ComunicaciónClientes
InternetGui
JSPs
Móv ilesGui
TagLibraries
ILUSTRACIÓN 38: COMUNICACIÓN 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.
INTRANET GUI
deployment Deployment Model
«business boundary»
ComunicacionPersonal
IntranetGUI
ILUSTRACIÓN 39: INTRANTET 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.
MANEJADOR DE PETICIONES
deployment Deployment Model
Manej ador de Peticiones
«business control»
Administrador de Serv icios
Manej ador de Procesos
Herramientas
ILUSTRACIÓN 40: MANEJADOR 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.
ADMINISTRADOR DE SERVICIOS
deployment Deployment Model
«business control»
Administrador de Serv icios
Manej ador de Procesos
Herramientas
ILUSTRACIÓN 41: ADMINISTRADOR 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.
SERVIDOR DE APLICACIÓN
deployment Deployment Model
Serv idor de Aplicación
«stub»
ReglasCon Externos
«business worker»
EJB de Trabaj o
SessionBeans
EntityBeans
MessageDriv enBeans
«case worker»
WebServ icesUsusarios
ILUSTRACIÓN 42: SERVIDOR 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.
ADMINISTRADOR DE CONSULTAS
deployment Deployment Model
Administrador de consultas
ILUSTRACIÓN 43: ADMINISTRADOR 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.
OTROS
deployment Deployment Model
«system»
SistemasHeterogeneos
ILUSTRACIÓN 44: SISTEMAS HETEROGÉNEOS
Este componente representa todas los diferentes sistemas con el que la aplicación K^2M debe
comunicarse como VISA, MASTERCARD, DATACREDITO etc.
VISTA DE IMPLEMENTACIÓN
ILUSTRACIÓN 45: VISTA DE IMPLEMENTACIÓN
DESCRIPCIÓN GENERAL DE LA VISTA DE IMPLEMENTACIÓ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.
ILUSTRACIÓN 46: DESCRIPCIÓN GENERAL
9.1.1 PRESENTACIÓN
ILUSTRACIÓN 47: PRESENTACIÓN ](VISTA 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.
Lógica del negocio
ILUSTRACIÓN 48: LÓGICA DE NEGOCIO (VISTA 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 persistencia
ILUSTRACIÓN 49: PERSISTENCIA (VISTA 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
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:
ILUSTRACIÓN 50: VISTA 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.
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.