<Sistema De Entretenimientos En Vuelos>

Documento de Arquitectura del Sistema1

(SAD)

Nombre del Equipo de Trabajo: <Alone>

Nombre de los Integrantes:

Cdigo :

Esta plantilla es basada en la plantilla disponible en:

http://sistemas.uniandes.edu.co/~isis3702/dokuwiki/doku.php?id=sad.

Seccin 1. Descripcin del Documento

1.1 Propsito y Audiencia
Breve descripcin de la organizacin y los usuarios a los que esta dirigido este documento
Soy estudiante de ingeniera de sistemas de la universidad Santiago de Cali, cursando la materia de
arquitectura de sistemas de informacin. Nos encontramos realizando un desarrollo de una aplicacin que
se encargue de facilitar la comodidad y satisfaccin de los pasajeros de un vuelo cualquiera el cual preste
este servicio de IFE que se refiere a las entretenciones disponibles en el avin para sus pasajeros durante
un vuelo, en este caso se va trabajar asimilando un proyecto propuesto por la profesora quien fue que puso
el tema y va dirigido a ella.
1.2 Organizacin del Documento
Descripcin de la organizacin del documento de arquitectura
Para llegar al objetivo de establecer una arquitectura buena, para el desarrollo del proyecto redactamos este
documento con la intencin de organizarlo de forma tal que sea de mucha ayuda, en primero lugar se hace
na breve descripcin del documento, donde resaltamos los aspecto ms importantes a tener en cuenta
durante el desarrollo de este. En segundo lugar describimos el proyecto haciendo nfasis en los aspectos
ms generales, tales como el problema, descripcin, objetivos, etc. Posteriormente, comenzamos a hablar
de los motivadores arquitecturales, los cuales incluyen los motivadores del negocio, los atributos de calidad
y las restricciones. A continuacin se menciona el contexto del proyecto, seguido de los estilos y tcticas
arquitecturales. Finalmente se define los puntos de vista y modelos arquitecturales, donde se incluye las
estrategias arquitecturales y se llevan a elaborar en nuestro proyecto.
1.3 Convenciones
Descripcin de las notaciones y smbolos utilizados en este documento
Posibles notaciones:
HAEC: Holmes Adrian Espinosa Camelo

1.4 Terminologa y Definiciones

Descripcin de los trminos utilizados en el documento y parte del dominio y contexto del problema
Program Administrador: este usuario podr crear editar y y deshabilitar programas.
Roles:

Facilitador lder
Facilitador Redactor.
Participante

Tecnologas: distribuyen los servicios prestados por el sistema de intermediacin comercial entre los
Customer Application Server y Supplier Application Server de la compaa,
ParalasconexionesqueseestablecendesdelasTouchScreens,manejandoprotocoloHTTP;teniendoen
cuentaquelasinteraccionesqueestosltimosestablecenconlaaplicacinintermediariasedanatravsde

unambienteWeb.
o
o
o
o

JEE:Java Enterprise Edition

EJB:EnterpriseJavaBeans
JPA:JavaPersistenceAPI
JDO:JavaDataObjects

1.5 Documentos Relevantes

Listado de documentos relevantes, utilizados durante el desarrollo de la arquitectura
Los siguientes documentos son importantes para el desarrollo de la arquitectura:

o
o

QAW. Captura y priorizacin de drivers

ADD. Attributes Driven Design. Realizar un diseo sistemtico de la arquitectura

VaB. Views and Beyond. Apoya en la documentacin del diseo.

ATAM. Anlisis de equilibrios arquitectnicos. Permite identificar riesgos en el diseo

o
o
o
o

Launch_v3.1
Documentacin prototipao
Documentacin requerimientos
strategy

Seccin 2. Generalidades del Proyecto

2.1 Problema a Resolver
Breve descripcin del problema o problemas ms relevantes que tiene el cliente en este momento.
El IFE que se desea modelar consiste inicialmente en una pantalla LCD sensible al tacto en cada asiento.
Esta pantalla sirve como centro de comando del pasajero.
El IFE deber ofrecer a los pasajeros diferentes tipos de entretenimiento e informacin del vuelo.
Esta debe poder transmitir pelculas de cine, series de televisin, noticieros y videos musicales on-demand.
Canales de televisin y msica pregrabada. Juegos on-demand. Mapas y ubicacin geogrfica,tiemporeal.
Tambin debe contar con llamadas telefnicas, tienda virtual y control de pasajero.

2.2 Descripcin General del Sistema a Desarrollar

Esta seccin describe la funcionalidad y el propsito del sistema o subsistemas cuya arquitectura es descrita
en este documento.
Teniendo en mente lo anterior se propone la construccin de una aplicacin de intermediacin para
arquitectura de software que permita la satisfaccin de las necesidades anteriormente planteadas. De esta
manera dicha propuesta contempla el desarrollo de un sistema de software distribuido cuya interaccin con
los usuarios finales se realizara por medio de un ambiente Web soportado por una capa de lgica de
negocio y otra de persistencia de los datos inherentes a los productos y clientes manejados por la empresa.
Tabla 1:
Id

Solicitudes del usuario

Solicitudes del usuario

Descripcin

Conectores de aplicaciones

El sistema debe s soportar conectores a aplicaciones desarrolladas en

java, process server, php,net,cobol

nico repositorio

El sistema debe integrar los distintos usuarios y generar un nico ID

y uno para el usuario de vuelo

Pantallas usuario final (Portal

de servicio)
4

Compatibilidad con dispositivos

Control del pasajero

El IFE que se desea modelar consiste inicialmente de una pantalla

LCD sensible al tacto, en cada asiento. Esta pantalla sirve como
centro de comando para el pasajero. EL IFE deber ofrecer a los
pasajeros diferentes tipos de entretenimiento
El sistema de permitir dispositivo externos como terminales de
micrfono y usb

El usuario podr contactar al personal de vuelo en

cualquier momento por medio de IFE, as como prender
o apagar la luz de cada silla.

Func.

Arq.
Sig.
x

x
X
eficie
ncia
X

Id
6

Solicitudes del usuario

Llamadas telefnicas

Descripcin

Func.

Este servicio se cobra por separado y la nica

forma de pago es con tarjeta de crdito. El IFE
debe incluir un lector de bandas magnticas y
conectarse con un sistema de pago de tarjetas de
crdito externo a todos los sistemas en el avin

2.3 Objetivos
Esta seccin describe los objetivos generales de la arquitectura del sistema dentro del contexto del ciclo de
vida del proyecto.
Continuacin se presenta los objetivos generales que guan el desarrollo de la arquitectura propuesta para la
construccin de la aplicacin intermedia para arquitectura de software.
1. ofrecer la percepcin del sistema implementar desde diferentes puntos de vista con el propsito
de lograr la satisfaccin de las necesidades planteadas por los stakeholders identificados en
arquitectura de software.
2. Proponer diferentes arquitecturas candidatas que ofrezcan la flexibilidad necesaria frente a los
requerimientos funcionales manifestados por los stakeholders y los requerimientos no
funcionales identificados durante la fase de levantamiento de informacin y a lo largo del
desarrollo de la arquitectura y su concentracin.
3. Desarrollar una herramienta de comunicacin para la definicin clara de necesidades e
identificacin adecuada de caminos de solucin por medio del diseo arquitectural realizado
logrando adicionalmente una optimizacin tanto de los recursos humanos como los financieros
que intervienen en la implementacin de la arquitectura elegida.

2.4 Stakeholders
Esta seccin presenta una lista de los stakeholders involucrados en el proyecto. Para cada uno de ellos, se
deben listar los concerns que van a ser tenidos en cuenta en el documento de arquitectura. Esta informacin
se presenta en forma de matriz, donde las filas representan los stakeholders y las columnas los concerns.
Cada celda determina el grado de relevancia del concern para el stakeholder (Tabla 2). Finalmente, basados
en los concerns relevantes a cada stakeholder se dermina los puntos de vista que se le presentarn.
El standard ANSI/IEEE 1471-2000 propone que al menos los siguientes stakeholders sean considerados:
usuarios, clientes, desarrolladores y administradores.

Customer
Application software
developers
Infrastructure software
developers
End users
Application system engineers
Application hardware
engineers

Project manager
Communications engineers

External organizations
Operational system managers

Chief Engineer/Chief
Scientist
Program management

Trainers
Maintainers

Auditors
Security engineers and
certifiers

System and software

integration and test engineers
Safety engineers and
certifiers

Arq.
Sig.

Tabla 2:

Listado de los Stakeholders

Stakeholder

Descripcin

Dueo de las aerolneas

Cliente de software

Cliente viajeros

Cliente de software

Desarrolladores

De tipo usuario

Administradores

De tipo usuario

Program administrator

De tipo usuario

Profesora de la materia del proyecto

Supervisor de avance del proyecto

Tabla 3:

Stakeholders y Expectativas
Stakeholder

Expectativas

Usuario final

Funcionalidad especifica del software

cliente

Atributos de calidad del negocio

supervisor

Tecnologa especificas a usar durante el desarrollo

Seccin 3. Motivadores Arquitecturales

3.1 Motivadores de Negocio

Esta seccin busca identificar los motivadores de negocio de la organizacin. Normalmente estos motivadores son encontrados,
respondiendo a las preguntas:
Cmo genera utilidad la organizacin
De dnde provienen las utilidades de la organizacin?
Cules son los elementos claves del negocio?
En resumen, un motivador de negocio es una descripcin corta que define clara y especficamente los resultados deseados de
negocio de una organizacin as como las actividades necesarias para lograrlos. Los motivadores de negocio deben ser:
Especficos, Medibles, Agresivos pero viables, Orientados al resultado y limitados en el tiempo.
El objetivo es hacer una lista priorizada de motivadores de negocio.
Ayuda para su uso:
El nombre del motivador: Sigue en general la regla: <verbo> + <elemento a medir> + <rea de nfasis>
o
Ejemplo: Incrementar ventas en las reas metropolitanas
La descripcin del motivador: Sigue en general la regla: <Retorno esperado del negocio>+ Mediante+ <Actividad
planeada de negocio>
o
Ejemplo: Incrementar ventas en 15 % mediante la apertura de nuevas oficinas
La medida: Define en una frase como valorar el impacto en el negocio del motivador. Se organiza por rangos y se
determina para cada rango, la unidad de medida del impacto. Adicionalmente, se definen los valores mnimos y
mximos para cada rango de impacto.
o
Ejemplo:
o
Medida: Crecimiento de las ventas en reas metropolitanas medido en millones de pesos
Ninguna : 0 0.9 millones
Bajo: 1 milln 99 millones
Moderado: 100 y 499 millones
Fuerte: 500 y 899 millones
Muy Fuerte: 900 millones o ms
La asociacin con el negocio define el motivador a que rea organizacional pertenece:
o
Ejemplo:
o
Definido Por: Gerente de Ventas
o
Ejecutado Por: Director y Ejecutivos de Ventas
o
Ubicacin en el portafolio: Servicios persona a persona

Nombre del Motivador

de Negocio
Innovar servicios IFE en
vuelos

Descripcin del Motivador de Negocio

Llamadas telefnicas: Este servicio se cobra

por separado y la nica forma de pago es con
tarjeta de crdito. El IFE debe incluir un lector de
bandas magnticas y conectarse con un sistema
de pago de tarjetas de crdito externo a todos los
sistemas en el avin. As mismo, debe incluir un
puerto para conectar el micrfono.
Control del pasajero: El usuario podr contactar
al personal de vuelo en cualquier momento por
medio de IFE, as como prender o apagar la luz de
cada silla.
Medida del Impacto

Enfrentar la crisis econmica que afecta actualmente a las aerolneas ,

especficamente a Aerolneas de los Alpes. En particular, la empresa desea atraer
nuevos usuarios y retener los actuales mediante un sistema de entretenimiento
confiable y econmico. Adicionalmente, la empresa considera que el IFE reducir
el nivel de stress de los viajeros, as como el nivel de atencin solicitada por lo
que se podr reducir la tripulacin de cada vuelo.

Nombre del Motivador

de Negocio

Descripcin del Motivador de Negocio

Generar ahorros economicos

Generar ahorros, econonomicos

mediante
implementacin de una plataformo que permita
evitar el crecimiento personal al disminuir la
cantidad de quejas por el usuario e implementar
servicios de informacin que sea gran atrativo
para el usuario de la aerolinea
Medida del Impacto

Reporte de quejas y reclamos mensuales con muestra de agrado

Nombre del Motivador
de Negocio

Descripcin del Motivador de Negocio

Tiempo y servicio

Se implementan servicios de llamadas el cual

puede ayudar a el servicio del cliente asi como el
depagos y
de eficiencias como el tiepo de
transaciones
Medida del Impacto

. Adicionalmente, la empresa considera que el IFE reducir el nivel de stress de los

viajeros, as como el nivel de atencin solicitada por lo que se podr reducir la
tripulacin de cada vuelo.

3.2 Restricciones de Tecnologa

Esta seccin describe las restricciones de tecnologa impuestas por la organizacin y/o el dominio del
problema
ID Restriccin
Res001
Descripcin:
Establecida por:

Tipo:
Nombre:
Tecnologa ( JEE )
Restriccin de arquitectura
Negocio ( arquitectura
de sistemas )
La aplicacin debe estar basada en componentes EJB.
Profesora de la materia arquitectura de
Sistemas de informacin

Alternativas:
Observaciones:
ID Restriccin
Res001
Descripcin:

No hay
No hay
Tipo:
Nombre:
Tecnologa ( EJB )
Restriccin de arquitectura
Negocio ( arquitectura
de sistemas )
La aplicacin se debe desarrollar utilizando un navegador por parte de los
usuarios

Establecida por:

Profesora de la materia arquitectura de

Sistemas de informacin

Alternativas:
Observaciones:

No hay
No hay

3.3 Restricciones de Negocio

Esta seccin describe las restricciones de negocio impuestas por la organizacin y/o el dominio del
problema
ID Restriccin

Descripcin:

Establecida por:

Tipo:
Nombre:
Tecnologa (JEE )
Restriccin de desarrollo
Negocio (( arquitectura
de sistemas )
1. Su tiempo de desarrollo no puede ser superior a un perdido de 4 meses para
lograr una ventaja competitiva real.
2. El IFE deber ser un sistema completamente independiente de los sistemas
del avin y el espacio requerido a nivel superior deber ser lo mnimo posible
Profesora de la materia arquitectura de
Sistemas de informacin

Alternativas:
Observaciones:

No hay
No hay

3.4 Atributos de Calidad

Perspectivas
Esta seccin describe el comportamiento de los atributos de calidad de los requerimientos que afectan la
arquitectura de software, incluidos escenarios de calidad.
Evolucin
Teniendoencuentalapresentearquitecturaylosrequerimientosnofuncionalesplanteadosporlos
stakeholders,esposiblegarantizarlacapacidaddeevolucindelsistema,considerandoeldiseofuncional
propuesto.Deestamanera,sepresentarconunmayorniveldedetalle,comolaarquitecturaelegidaexhibe
deunaformaadecuadaelcumplimientodeesteatributodecalidad,as.
Calidad deseada
Laarquitecturadesoftwaredesarrollada,ofreceunaflexibilidadadecuadafrentealaadiciny/oreemplazo
decomponentesfuncionalesdelsistema.Sinembargo,encasodemodificary/oreemplazaruncomponente
determinado,esnecesarioqueestasalteracionesrespetenlasinterfacesrequeridasaligualquelosservicios
queofrecen.
Aplicabilidad
Teniendoenmenteloanterior,esposibledecirqueestaperspectivaafectademaneratransversalalpunto

devistafuncionalyenigualmagnitud,alpuntodevistadeinformacin,dadoqueestaflexibilidaddel
sistemafrentealcambio,solopuedeserlogradaatravsdelaestructuradecomponentesofrecida,los
serviciosmanejadospormediodelasinterfacesdiseadas,laestructuraestticadedatospresentada,los
estadosdefinidosparalasunidadesinformacionalesylosflujosdedatosidentificadosentrecomponentes.
Sinembargo,conloanteriornoseestafirmando,queestaperspectivanoafecteotrospuntosdevista;sino
quesuinfluenciaesmayorenlosviewpointcontemplados.
Concerns
Especficamente, se espera que la arquitectura no se vea comprometida de manera crtica, al inducir un
cambio en su estructura de componentes y por ende, es su estructura de unidades informacionales.
Actividades
Las actividades para aplicar esta perspectiva de evolucin a los puntos de vista funcional y de informacin,
son los siguientes.
Esta seccin describe el comportamiento y los atributos de calidad de los requerimientos que afectan la
arquitectura de
Software, incluidos escenarios de calidad.

Identificar claramente los cambios a inducir en el sistema, para la evolucin deseada.

Evaluar la flexibilidad actual del sistema frente al tipo de cambios identificados. Adicionalmente,
analizar el impacto en para el caso de modificacin, reemplazo y/o eliminacin de componentes
desde el functional viewpoint y las consecuencias de estas alteraciones, en las estructuras de datos,
estados y flujos de informacin
Plantear los tradeoff posibles frente a los cambios identificados y su impacto en los puntos de vista
funcional y de informacin.
Finalmente, implementar los cambios arquitecturales a los que haya lugar, teniendo en cuenta las
consideraciones y resultados, obtenidos por medio de esta perspectiva de evolucin.

Tcticas
Las aproximaciones y precisiones necesarias para el cumplimiento del atributo de modificabilidad,
comprenden bsicamente la conservacin del esquema de servicios que se tiene a travs de las interfaces
diseadas, la agrupacin de los elementos arquitecturales por su grado de especializacin, frente a las reglas
del negocio identificadas en IFE

3.4.1 Listado de Escenarios de Calidad

No.

ATRIBUTO

ESC-001

Usabilidad

ESC-003

Modificabilidad

ESC-004

Disponibilidad

ESC-005

Seguridad

ESC-006

Eficiencia

ESCENARIOS DE CALIDAD

3.4.2 Escenarios de Calidad

Escenario de Calidad #
Atributo de Calidad
Justificacin
Fuente
Estmulo
Artefacto
Ambiente
Respuesta
Medida de la
Respuesta

Stakeholder:

Usabilidad
Se desea impelmentar un sistema bluetooth para pc
Producto.
Agregar un cambio (insertar/eliminar) algn componente multimedia
Sistema infrarrojo
Se tiene un ambiente de desarrollo implemetacion de dispositivo de con una
aplicacion para llamadas mediante sistema inlambrico
Se puede contestar con un dispositivo bluetooh y realizar llamadas .
El cambio es se mejor usabilidad de las llamadas y conformidad y menos
tiempo de espera para respuesta, el ususario debe poder usar el IFE sin
necesidad de pedir ayuda a la tripulacin

Escenario de Calidad #
Atributo de Calidad
Justificacin

Fuente
Estmulo
Artefacto
Ambiente

Respuesta

Medida de la
Respuesta

Stakeholder:

eficiencia
En este se garantiza que el usuario tenga el servicio sin tiempos
extremadamente largos de respuesta.

clientes
Congestin en el sistema IFE
Servidor de aplicacciones central
Ambiente de ejecucin normal
El sistema debe estar en capacidad de responder a las solicitudes del usuario en
un tiempo considerablemente corto a pesar del numero de usuarios que este est
corriendo simultneamente
El sistema debe responder a las solicitudes del usuario en un tiempo no mayor a
3 segundos cuando este el 99% de la carga total del avin. Y debe responder
inmediatamente con el 80%
.

Escenario de Calidad #
Atributo de Calidad

Justificacin

Fuente
Estmulo
Artefacto

Ambiente

Respuesta

Medida de la
Respuesta

Stakeholder:

Modificabilidad
Se desea adicionar un campo a la informacin de un producto, de forma tal que
las alteraciones en la capa WEB, en la lgica de negocio, en la capa de
persistencia y en las estructuras de datos, se implementen en menos de 50
minutos, impactando el mnimo nmero de componentes funcionales y
entidades informacionales.
Producto.
Agregar un cambio (insertar/eliminar) algn componente multimedia
Las entidades del sistema, los session bean, los entity bean y la capa WEB.
Se tiene un ambiente de desarrollo NetBeans IDE con el proyecto creado y listo
para hacer deployment. Ya fue probado el deployment del componente antes del
cambio.
Los desarrolladores logran hacer el cambio y hacer deployment sin errores, las
tablas de la base de datos son actualizadas para las nuevas entidades al hacer
deployment y la interfaz grfica permite crear los clientes con el nuevo campo.
El cambio y su despliegue el Glass Fish toma menos de 10 minutos.

Escenario de Calidad #
Atributo de Calidad

Justificacin

Fuente
Estmulo
Artefacto
Ambiente

Stakeholder:

Disponibilidad
no puede responder a las peticiones de informacin que se le estn haciendo
desde los browsers de los mismos clientes. Se requiere, que el sistema de
intermediacin comercial vuelva a responder al 95% de las peticiones en un
periodo inferior a 10 minutos, utilizando el servicio de backup del clster de
servidores de clientes y redistribuyendo la carga transaccional del servidor de
aplicaciones principal a los dems servidores funcionales.
clientes
Consulta de carrito de compra virtual.
Servidor de aplicacciones central
Se da el estmul en un ambiente de ejecucin normal en un contenido de
aplicaciones GlassFish que ha venido funcionando sin inconvenientes

Respuesta

Medida de la
Respuesta

Volver a responder a dichas peticiones, utilizando el servicio de backup del

clster de servidores de clientes y redistribuyendo la carga transaccional del
servidor de aplicaciones principal a los dems servidores funcionales.
Este sistema de backup y de balanceo de carga debe entrar a responder el 95%
de las peticiones no resueltas por parte de los browsers de los clientes, en un
periodo inferior a 10 minutos.
.

Escenario de Calidad #
Atributo de Calidad

Justificacin

Fuente
Estmulo
Artefacto

Ambiente

Respuesta

Medida de la
Respuesta

Stakeholder:

Modificabilidad
Se desea adicionar un campo a la informacin de un producto, de forma tal que
las alteraciones en la capa WEB, en la lgica de negocio, en la capa de
persistencia y en las estructuras de datos, se implementen en menos de 50
minutos, impactando el mnimo nmero de componentes funcionales y
entidades informacionales.
Producto.
Agregar un cambio (insertar/eliminar) algn componente multimedia
Las entidades del sistema, los session bean, los entity bean y la capa WEB.
Se tiene un ambiente de desarrollo NetBeans IDE con el proyecto creado y listo
para hacer deployment. Ya fue probado el deployment del componente antes del
cambio.
Los desarrolladores logran hacer el cambio y hacer deployment sin errores, las
tablas de la base de datos son actualizadas para las nuevas entidades al hacer
deployment y la interfaz grfica permite crear los clientes con el nuevo campo.
El cambio y su despliegue el Glass Fish toma menos de 10 minutos.

Escenario de Calidad #
Atributo de Calidad
Justificacin

Fuente
Estmulo
Artefacto
Ambiente

Respuesta
Medida de la
Respuesta

Stakeholder:

concurrencia
debe soportar la concurrencia de manera confiable. Se espera
que en promedio 200 usuarios interacten con el IFE
concurrentemente
producto
Congestin en el sistema IFE
Servidor de aplicacciones central
El sistema debe ser altamente escalable
Se espera que en promedio 200 usuarios interacten con el IFE
concurrentemente. Un usuario no debe esperar ms de 3
segundos en recibir una respuesta ante una solicitud y no debe
recibir video o audio con cortes o saltos
Se espera que en promedio 200 usuarios interacten con el IFE
concurrentemente. Un usuario no debe esperar ms de 3
segundos en recibir una respuesta ante una solicitud y no debe

recibir video o audio con cortes o saltos.

Seccion 4. Estilo y Tcticas Arquitecturales

Nombre
Descripcin

Cliente - Servidor
Los usuarios invocan la parte cliente de la aplicacin, que construye una
solicitud para ese servicio y se la enva al servidor de la aplicacin que usa
TCP/IP como transporte.

Trade-offs

Seccin 5. Contexto
5.1 Listado de Casos de Uso por Actor
En este modelo se identificaron diferentes tipos de actores mencionados acontinuacion:
Administrador del Sistema: Este es capaz de hacerle modificaciones de alto nivel al sistema tales como
agregar contenido y eliminar contenido del sistema IFE.
Pasajero Turista: este cuenta con la capacidad de ver contenido el sistema IFE incluyendo todas las
opciones de entretenimiento.
Pasajero Ejecutivo: Se le pone a disposicin un sistema ms rpido que el del pasajero turista y tiene un
men diferente de entrada al sistema. Tambin cuenta con la misma funcionalidad del pasajero turista
Pasajero Infantil: Este tiene a disposicin un men ms amigable con unos juegos personalizados y
algunos de los contenidos ofrecidos no son bloqueados.
Tripulacin de Vuelo: esta tiene la opcin de hacer llamadas a los pasajeros y tomar control de alguna de
las pantallas en caso de mal uso.

5.2 Diagrama de Casos de Uso

Seccin 6. Puntos de Vista y Modelos Arquitecturales

Esta seccin presenta los puntos de vista de la arquitectura del sistema. Comenzando por una breve
descripcin de la estrategia arquitectural.

Primero se debe considerar que un elemento de arquitectura hace referencia a una pieza fundamental a
considerar cuando se realiza la construccin o definicin de un sistema. Lo cual quiere decir que los
siguientes elementos son vitales para la adecuada definicin de la arquitectura de un sistema
computacional:

Stakeholders - Interesados: Hace referencia a una persona, grupo o entidad que est interesada, que genera
requerimientos, objetivos o refleja sus aspiraciones y expectativas en la elaboracin de la arquitectura del
sistema.

Architectural Descriptions - Descripcin de arquitectura (AD): Son una serie de entregables que permiten
documentar la arquitectura del sistema. Con estos documentos los cuales los Stakeholders, pueden tener
una mayor claridad, entendimiento y satisfaccin demostrada, sobre el cumplimiento de todas sus
expectativas en la definicin de la arquitectura.

View - Vista: Es una representacin de uno o ms elementos de la estructura de la arquitectura, que ilustran
o representan un set de componentes del sistema y sus respectivas relaciones. Una descripcin de una
arquitectura se compone de una o varias vistas.

ViewPoints - Puntos de Vista: Es una especificacin que describe los patrones, plantillas y sus conversiones
para un determinado Stakeholders y sus correspondientes expectativas. En estas se identifican las
relaciones con otros puntos de vista, sus guas, diagramas, principios y plantillas, las cuales servirn como
guas para crear el documento de arquitectura AD. Un punto de vista es un patrn para construir una vista.
Entre los puntos de vista ms utilizados se encuentra el punto de vista funcional, punto de vista de
despliegue, punto de vista de informacin, entre otros.

Architectural Perspective o Perspectiva de arquitectura: Se define como la coleccin de actividades,

tcticas y pautas, utilizadas para asegurar la identificacin de un grupo de atributos y propiedades de
calidad, las cuales deben considerarse alrededor de un variado nmero de vistas de la arquitectura del
sistema. Entre las perspectivas ms utilizadas estn la seguridad, eficiencia, fiabilidad, mantenimiento,
entre otros.

6.1 Punto de Vista Funcional

En esta seccin se presenta el punto de vista funcional

6.1.1 Diagrama de Clases

6.1.2 Modelo de Componentes

Conrespectoaestemodeloyteniendoencuentalafigura,esposiblevisualizarqueelservercorede
IFE maneja un ancho de banda en sus conexiones de 10 Gbps, con el fin de proporcionar
transferenciasdeinformacindealtavelocidadysoportarmltiplesconexiones,conlaayudadeun
protocolodetransportecomoelTCP.
Porotrolado,lasconexionesqueseestablecendemaneraremotaconlaaplicacinIFE,porpartede
clientesyproveedores,secontemplanconvelocidadesaproximadasde300Kbpscomomnimo,con
elfindecontribuiralrequerimientodetiemposderespuestarpidos.Sinembargo,dentrodelaredde
realocalseofrecenvelocidadesdemnimo100Mbpsparalasconexionesqueseestablecendesde
lasTouchScreens,manejandoprotocoloHTTP;teniendoencuentaquelasinteraccionesqueestos
ltimosestablecenconlaaplicacinintermediariasedanatravsdeunambienteWeb.
Esasqueacontinuacin,sedescribedemaneradetalladalasinterfacesdeinterconexinderedque
seproponen,paraelcorrectofuncionamientodelaaplicacinIFE

6.2 Punto de Vista de Despliegue

En esta seccin se presenta el punto de vista de despliegue
Descripcin
A travs de los siguientes modelos de plataforma de ejecucin, red y de dependencias tecnolgicas, es
posible observar que la propuesta arquitectural pretende utilizar un servidor de aplicaciones corporativo,
encargado de centralizar la funcionalidad de la aplicacin intermediaria; permitiendo la sincronizacin de
los servicios de almacenamiento, la presentacin de la informacin a travs de un ambiente WEB;
distribuyendo los servicios prestados por el sistema de intermediacin comercial entre los Customer
Application Server y Supplier Application Server de la compaa.
De igual forma es posible, observar que el Server Core est conformado, por los WEB Server, Corporate
Application Server, Database Server, Customer Application Server y Supplier Application Server; de
manera tal, que esta regin del sistema est siendo protegida a travs de un sistema de Firewall que regulan
las conexiones establecidas por parte de usuarios externos como clientes y proveedores de IFE.

6.2.1 Diagrama de Deployment