1.

Contextualización y Alcance de la solución

[Esta es una sección que describe el contexto de la solución y si se puede, utilizar un diagrama de muy alto nivel que
describa la arquitectura de la solución]
2. Contexto de la Solución
[Esta es una sección que describe los componentes que hacen parte de la solución. Pueden enumerarse los componentes y
si se puede, utilizar un diagrama de componentes de alto nivel que describa la arquitectura de la solución]

Datos de
homologación

Sistema Origen Integrador Sistema Destino

Figura 1. Contexto de la Solución

2.1 Sistemas involucrados

[En esta sección se deben incluir todos los sistemas involucrados en la solución]

2.1.1 Sistema 1
[Este sistema está encargado de brindar asistencia telefónica a los clientes de la Cía “X”en
Descripción un contexto IVR (Interactive Voice Response). Corresponde al canal telefónico del entorno
de la Cía “X”. ]

Dueño [Cía “X” <TBD>]

[El contacto para los temas relacionados con este sistema designado por la Cía “X” es
Contacto
XXXXX].

Hardware [IBM Pseries 595 – Arquitectura Power 6]

Inferior (S.0) [IBM AIX 5.3]

Plataforma [Oracle 10g
Superior J2EE App Tier
WAS 6.1 NDM]
 [Los estilos de integración soportados indican las posibilidades que contempla la aplicación
para integrarse con otros sistemas:
Mensajería: La aplicación se conecta a un sistema de mensajería definido, e intercambia
información y/o funcionalidad a partir de mensajes específicos.
Estilos de Invocación Remota de Procedimientos: La aplicación expone operaciones que pueden ser
Integración invocados de manera remota y permiten intercambiar información y/o funcionalidad
Base de Datos Compartida: La información que la aplicación desea compartir se almacena
en una base de datos común con otras aplicaciones.
Transferencia de Archivos: La aplicación produce archivos de datos compartidos para que
otros sistemas consuman, y viceversa.]

[Los estilos técnicos de comunicación soportados indican la cantidad de sesiones y

conexiones inmersas en un intercambio de información
Sincrónico: Indica que toda la comunicación se realiza en una misma sesión, sobre la misma
Estilo Técnico de conexión.
Comunicación
Asincrónico: La comunicación se realiza en dos pasos. En un primer paso la aplicación
origen envía la información hacia la aplicación destino, y en un segundo paso la aplicación
destino envía la información de respuesta hacia la aplicación origen. En este caso tenemos
más de una sesión, y podemos tener varias conexiones.]

[Los estilos aplicativos de comunicación soportados indica la cantidad de comunicaciones y

el sentido (origen - destino) en que se realizan
Request/Response: La aplicación origen envía una solicitud a la aplicación destino y se
queda esperando hasta que la aplicación destino envíe la respuesta (two-way).
Fire and Forget: La aplicación origen envía información a la aplicación destino sin esperar
Estilos
que la aplicación destino entregue alguna respuesta de vuelta (one-way).
Aplicativos de
Comunicación Call Back: La aplicación origen envía una solicitud a la aplicación destino sin esperar que la
aplicación destino entregue la respuesta; una vez la aplicación destino, procesa la solicitud,
envía la información requerida invocando una operación específica de la aplicación origen.
(dos comunicaciones “one-way”).
Publish and Suscribe: La aplicación origen envía un tópico que publica en modo difusión y
las aplicaciones interesadas en el tópico se suscriben a ella para recibir la información.]

Transporte [Ej: HTTP, TCP, FTP, etc.]

Mensajería [ Trama Plana -> ISO 8583, etc.

(Estructura de mensajes) XML- > Ej: IFX, MXML, FIXML,etc.]

Protocolos [Asociado al estilo aplicativo de comunicación se debe indicar

si se requiere de algún tipo de protocolo de comunicación
Comunicación adicional.
Ej: En un esquema request/response hay paginación en los
mensajes por limitaciones de canal y/o de la aplicación.]
3. Requisitos
3.1 Requisitos Funcionales
[Los requisitos funcionales asociados al componente de integración son:]

3.1.1 Requisito funcional 1

Diagrama de Secuencia requisito funcional 1:

Stma de procesos Aplicativo origen Integrador Homologador Aplicativo destino

1. Ejecutar Interfaz

2. Leer Origen

3. Validar y
Transformar

4. Homologar

5. Escribir Destino

Figura 2. Secuencia de pasos.

[Describir los pasos del diagrama de secuencia]

[Ej: 1. Ejecutar interfaz: Sistema de Procesos ejecuta el servicio de DataStage para la ejecución de la Interfaz.

2. Leer origen: El integrador lee por medio de ftp el archivo origen.]

3.2 Requisitos No Funcionales

[Los requisitos no funcionales asociados al componente de integración son: Ventana de mantenimiento, Seguridad,
Esquema de Disponibilidad, Horario de disponibilidad, etc]

3.2.1 Requisito no funcional 1

Aplicación RNF1 RNF2 … RNFn

Aplicación 1
… Aplicación N
4. Vista General de la Arquitectura de la Solución
La realización del escenario de integración entre los diferentes aplicativos para la funcionalidad planteada se presenta a
continuación.
[Aquí debemos incluir el diagrama detallado de la solución -Diagrama de Despliegue-]

XML/HTTPS

Figura 3. Vista Física de la Solución.

5. Modelo Aplicativo
Diagrama de clase del sistema

6. Modelo físico de componentes técnicos

 Diagrama del modelo físico de componentes

  Descripción del modelo físico de componentes a nivel técnico

REC: s el sistema encargado de realizar todas las operaciones de recaudos. Por medio de este las personas hacen pagos de
los servicios públicos.
Generador Req y Resp: Generador de tramas e intérprete de las respuestas que van a ser enviadas para el consumo de los
servicios del Aplicativo 1.
Programa 1: Servidor que se encarga de activar las instancias del cliente de mensajería MQ (poner y leer mensajes de colas
MQ).
Componente 1: aplicativo cliente del servidor MQ encargado de atender las solicitudes para envío y lectura de mensajes de
colas MQ.
Componente 2: API que provee IBM para Java poder ejecutar llamados con cliente al MQ Server.

1.3 Consideraciones