HISTORIAL DE CAMBIOS

VERSIN FECHA DESCRIPCIN ENCARGADO

0.0.1 25 de Julio de 2013 Creacin de la seccin 1 Jonathan Len
0.0.2 27 de Julio de 2013 Creacin de la seccin 2 Jonathan Len
0.1.0 30 de Julio de 2013 Revisin general Jonathan Len
0.1.1 8 de Agosto de 2013 Creacin de la seccin 3 Jonathan Len
0.1.2 9 de Agosto de 2013 Creacin de la seccin 3 Jonathan Len
0.2.0 10 de Octubre de 2013 Revisin general Jonathan Len
0.2.1 10 de Octubre de 2013 Correccin general Jonathan Len
0.2.2 7 de Noviembre de 2013 Creacin lista de ilustraciones Jonathan Len
0.2.3 7 de Noviembre de 2013 Creacin lista de tablas Jonathan Len
0.2.4 7 de Noviembre de 2013 Creacin de la bibliografa Jonathan Len
0.2.5 8 de Noviembre de 2013 Creacin de las definiciones Jonathan Len
0.2.6 8 de Noviembre de 2013 Creacin de la tabla de contenido Jonathan Len
0.3.0 11 de Noviembre de 2013 Revisin general Jonathan Len
0.3.1 11 de Noviembre de 2013 Correccin general Jonathan Len
0.3.2 14 de Noviembre de 2013 Creacin de la portada Jonathan Len
0.3.3 15 de Noviembre de 2013 Actualizacin de hipervnculos Jonathan Len
1.0.0 15 de Noviembre de 2013 Lanzamiento Jonathan Len
 TABLA DE CONTENIDO

HISTORIAL DE CAMBIOS ............................................................................................... 1

TABLA DE CONTENIDO ................................................................................................. 3
LISTA DE ILUSTRACIONES ........................................................................................... 4
LISTA DE TABLAS ........................................................................................................... 5
1. INTRODUCCIN ...................................................................................................... 6
1.1. PROPSITO ...................................................................................................... 6
1.2. ALCANCE .......................................................................................................... 6
1.3. DEFINICIONES, ACRNIMOS Y ABREVIACIONES ...................................... 7
1.4. REFERENCIAS Y BIBLIOGRAFA.................................................................... 8
1.5. APRECIACIN GLOBAL................................................................................... 9
2. REPRESENTACIN ARQUITECTURAL ............................................................... 10
2.1. VISTA LGICA ................................................................................................ 10
2.2. VISTA DE IMPLEMENTACIN ....................................................................... 10
2.3. VISTA DE DESPLIEGUE ................................................................................ 10
2.4. VISTA DE CASOS DE USO ............................................................................ 10
3. VISTAS .................................................................................................................... 11
3.1. VISTA DE CASOS DE USO ............................................................................ 11
3.2. VISTA LGICA ................................................................................................ 13
3.2.1. OVERVIEW ARQUITECTURA ................................................................ 13
3.2.2. VISTA LGICA ......................................................................................... 14
3.3. VISTA DE IMPLEMENTACIN ....................................................................... 15
3.4. VISTA FSICA .................................................................................................. 16
4. TACTICAS ARQUITECTURALES .......................................................................... 17
4.1. DISPONIBILIDAD ............................................................................................ 17
4.2. ESCALABILIDAD ............................................................................................. 18
4.3. INTEGRACIN ................................................................................................ 18
4.4. INTEROPERABILIDAD ................................................................................... 19
4.5. MANTENIMIENTO ........................................................................................... 20
4.6. PORTABILIDAD ............................................................................................... 21
4.7. RENDIMIENTO ................................................................................................ 22
4.8. SEGURIDAD .................................................................................................... 23
 LISTA DE ILUSTRACIONES

Ilustracin 1. Modelo de vistas arquitecturales 4+1 ...........................6

Ilustracin 2. Casos de uso ...............................................................11
Ilustracin 3. Overview arquitectura .................................................13
Ilustracin 4. Vista lgica ..................................................................14
Ilustracin 5. Vista de implementacin .............................................15
Ilustracin 6. Vista fsica ...................................................................16
 LISTA DE TABLAS

Tabla 1. Definiciones, acrnimos y abreviaciones ............................................. 7

Tabla 2. Disponibilidad - Ping/Echo ................................................................. 17
Tabla 3. Disponibilidad - Remocin desde el servicio...................................... 17
Tabla 4. Escalabilidad - Scale up .................................................................... 18
Tabla 5. Escalabilidad - Scale out ................................................................... 18
Tabla 6. Integracin - Minimizacin de interfaces ............................................ 18
Tabla 7. Integracin - Conjunto limitado de protocolos de interaccin ............. 19
Tabla 8. Integracin - Bajo acoplamiento y alta cohesin ................................ 19
Tabla 9. Interoperabilidad - Minimizar la complejidad externa de los
componentes .................................................................................................. 19
Tabla 10. Interoperabilidad - Establecer los nombres de los servicios de los
componentes .................................................................................................. 20
Tabla 11. Mantenimiento - Protocolos de comunicacin adecuados ............... 20
Tabla 12. Mantenimiento - Diseo coherente de los componentes ................. 20
Tabla 13. Mantenimiento - Cdigo fuente legible y manejable ........................ 21
Tabla 14. Mantenimiento - Documentacin clara y completa .......................... 21
Tabla 15. Portabilidad - Mquinas virtuales ..................................................... 21
Tabla 16. Portabilidad - Uso de interfaces estandar entre componentes ......... 22
Tabla 17. Rendimiento - Incremento de eficiencia computacional ................... 22
Tabla 18. Rendimiento - Reducir la sobrecarga computacional ....................... 22
Tabla 19. Rendimiento - Concurrencia ............................................................ 23
Tabla 20. Rendimiento - Mantener mltiples copias ........................................ 23
Tabla 21. Seguridad - Usuarios autenticados .................................................. 23
Tabla 22. Seguridad - Usuarios autorizados ................................................... 24
Tabla 23. Seguridad - Integridad de datos ...................................................... 24
Tabla 24. Seguridad - Limitacin de exposicin .............................................. 24
1. INTRODUCCIN

El documento presentado describe la documentacin de la arquitectura de

la aplicacin mvil Calean, la cual es una aplicacin de localizacin de
vendedores de bienes y/o servicios y la comunicacin entre estos y los
posibles compradores.

El objetivo del presente documento es presentar la documentacin de la

arquitectura del sistema en forma ordenada, clara y coherente durante la
realizacin, puesta en marcha y operacin del mismo.

1.1. PROPSITO

El documento de arquitectura de software (SAD) desarrolla la

documentacin de la arquitectura del sistema empleando el modelo
de vistas arquitecturales 4+1 de Philippe Kruchten [1].
Ilustracin 1. Modelo de vistas arquitecturales 4+1

Usuario final Programadores

Funcionalidad Administracin de software

Vista de
Vista lgica
implementacin
Vista de casos
de uso
Vista de
Vista de proceso
despliegue

Integradores Ingenieros de Sistemas

Rendimiento Topologas
Escalabilidad Comunicaciones
Fuente: [1]

1.2. ALCANCE

El alcance del presente documento es describir de forma concreta la

arquitectura propuesta para el sistema, empleando el conjunto de
vistas arquitecturales 4+1 [1] teniendo en cuenta los componentes y
conectores de Java EE.
1.3. DEFINICIONES, ACRNIMOS Y ABREVIACIONES

Tabla 1. Definiciones, acrnimos y abreviaciones

CONCEPTO DEFINICIN
Es un servidor de aplicaciones libre de Oracle, que
implementa las tecnologas desarrolladas en la
Glassfish
plataforma Java EE y permite ejecutar aplicaciones
desarrolladas bajo este lenguaje.
Una funcin hash es una funcin obtenida mediante un
algoritmo, que tiene como entrada un conjunto de
Funcin Hash elementos y los convierte en un rango de salida finito,
normalmente cadenas. La funcin asegura la
consistencia de los datos enviados a travs de la red.
El protocolo de transferencia de hipertexto es el
HTTP protocolo usado en cada transaccin que se ejecuta
en la web.
Es una plataforma de programacin para desarrollar y
ejecutar aplicaciones en lenguaje de programacin
Java EE
java. Est enfocada para aplicaciones con gran
cantidad de transacciones y/o empresariales.
Es un mecanismo usado en Java para invocar de
RMI
manera remota un mtodo.
Es un concepto de arquitectura de software que define
SOA la utilizacin de servicios para dar soporte a los
requisitos de un negocio.
Es uno de los principales protocolos de internet. Se
TCP pueden usar conexiones TCP para crear conexiones
entre dos nodos para enviar un flujo de datos.
Es el lenguaje de modelado de sistemas ms conocido
UML
y utilizado en el mundo.
Es una tecnologa que utiliza intercambio de mensajes
XML y que permite a dispositivos externos a un
WebService
sistema, acceder a l sin necesidad de
implementaciones adicionales.
Es un formato XML que se utiliza para describir
WSDL
servicios web
Fuente: [2]
1.4. REFERENCIAS Y BIBLIOGRAFA

[1] P. B. Kruchten, The 4+ 1 view model of architecture, Softw.

IEEE, vol. 12, no. 6, pp. 4250, 1995.

[2] P. M. Walker, Larousse dictionary of science and technology.

Larousse plc, 1995.

[3] IEEE Recommended Practice for Architectural Description of

Software-Intensive Systems, IEEE Std 1471-2000, pp. i23,
2000.

[4] J. P. Lawler and H. Howell-Barber, Service-oriented architecture:

SOA strategy, methodology, and technology. CRC Press, 2007.

[5] Carreo, Julio, Arquitectura de software. Documenting SA 4+1

Model, Pontificia Universidad Javeriana.

[6] Carreo, Julio, Arquitectura de software. Generacin de

escenarios RNF., Pontificia Universidad Javeriana.

[7] Carreo, Julio, Arquitectura de software. Escenarios SEI para

definir RNF, Pontificia Universidad Javeriana.

[8] Developing a J2EE Architecture with Rational Software Architect

Using the Rational Unified Process.

[9] G. A. W. App, Software Architecture Document.

[10] G. Mundo Bosch, Software Architecture Document, 2013.

[11] L. Bass, P. Clements, and R. Kazman, Software Architecture in

Practice, 2/E. Pearson Education India, 1998.

[12] F. Buschmann, K. Henney, and D. Schimdt, Pattern-oriented

Software Architecture: On Patterns and Pattern Language, vol. 5.
John Wiley & Sons, 2007.

[13] P. C. Clements, Software architecture in practice, Carnegie

Mellon University, 2002.
1.5. APRECIACIN GLOBAL

En el presente documento se podr encontrar el diseo arquitectural

del sistema, tanto de la aplicacin mvil como del servidor que
consume la informacin.

1 Parte Introduccin

Esta seccin se encarga de presentar las razones por las

cuales se desarrolla este documento, su propsito y el
alcance de la aplicacin a desarrollar.
Presenta trminos y abreviaciones utilizados en el
documento.
Presenta las referencias y bibliografa consultada para el
desarrollo de este documento.

2 Parte Representacin arquitectural

Describe el uso, audiencia y relaciones de las vistas.

3 Parte Vistas

En esta seccin se encuentran las vistas descritas en la

seccin 2. REPRESENTACIN ARQUITECTURAL.

4 Parte Tcticas arquitecturales

Describe las tcticas empleadas en el diseo de la

arquitectura con el fin de respaldar los escenarios de
calidad.

El estndar que se sigue para la elaboracin de este documento es el

1471 de 2000 de la IEEE [3].
2. REPRESENTACIN ARQUITECTURAL

Teniendo en cuenta el modelo de vistas arquitecturales 4+1 de Philippe

Kruchten [1], las vistas usadas para documentar la arquitectura del sistema
son:

2.1. VISTA LGICA

En la vista lgica se representa la funcionalidad que el sistema

proporcionar a los usuarios finales. Esta representa lo que la
aplicacin debe hacer as como las funciones y servicios que ofrece.
Esta vista est orientada a los diseadores.

Se presenta un overview de la arquitectura del sistema. Este es un

primer vistazo a lo que podra ser una posible particin de
responsabilidades dentro del sistema en su etapa de implementacin.
Cabe recordar que durante cada una de las iteraciones del proyecto,
se ir cambiando para su mejora.

2.2. VISTA DE IMPLEMENTACIN

La vista de implementacin muestra la aplicacin mvil desde la

perspectiva de un programador y se encarga de mostrar cmo est
dividido el sistema (componentes) y su relacin (dependencias). Para
ofrecer una mejor documentacin de esta vista, se usarn diagramas
de componentes UML y de paquetes UML. Esta vista est orientada a
los programadores.

2.3. VISTA DE DESPLIEGUE

En esta vista se muestran todos los componentes fsicos del sistema,

as como las conexiones fsicas entre esos componentes segn la
perspectiva de un ingeniero de sistemas. Para ofrecer una mejor
documentacin de esta vista, se usar el diagrama de despliegue
UML. Esta vista est orientada a los administradores de despliegue.

2.4. VISTA DE CASOS DE USO

La vista de casos de uso se encarga de relacionar y unir las 4 vistas

anteriores. Gracias a esto se puede tener una trazabilidad de
componentes, clases, equipos, paquetes, bases de datos, etc., para
cada caso de uso que se tenga. Para ofrecer una mejor
documentacin de esta vista, se usar el diagrama de casos de uso
UML propuesto en el documento [Calean] - Software requirements
specification.pdf. Esta vista est orientada a todos los stakeholders
del sistema incluyendo los usuarios finales.
3. VISTAS

3.1. VISTA DE CASOS DE USO

Teniendo en cuenta los requerimientos (priorizados) y los casos de

uso (con documentacin) presentados en el documento [Calean] -
Software requirements specification.pdf, se ha elaborado un diagrama
de casos de uso. Este da una perspectiva global de la funcionalidad
del sistema y nos permiten diferenciar las reas del sistema que
tienen mayor importancia.
Ilustracin 2. Casos de uso

Fuente: Creacin propia

Cambiar estado: El vendedor puede cambiar su estado para ser

visible/invisible a los compradores.

Crear perfil: El usuario puede crear un perfil de tipo comprador o

vendedor.

Iniciar sesin: El usuario puede iniciar sesin en la aplicacin mvil.

Buscar vendedores: El comprador/vendedor puede buscar

vendedores cercanos a su posicin, dependiendo de los criterios de
bsqueda.
Seleccionar vendedor: El comprador/vendedor puede seleccionar el
vendedor que a su parecer, sea el mejor.

Iniciar chat: El comprador/vendedor puede iniciar una sesin de chat

con el vendedor seleccionado en el caso de uso anterior.

Crear cita: El comprador/vendedor puede agendar una cita con el

vendedor para llegar a un acuerdo presencial de compra.

Finalizar cita: El comprador/vendedor puede finalizar una cita

agendada en cualquier momento.

Calificar cita: El comprador/vendedor puede calificar el resultado de la

cita para la retroalimentacin del comprador/vendedor.

Gestionar usuarios: El administrador puede realizar operaciones de

borrado, actualizacin y vista de los datos de los usuarios. Los datos
sensibles del usuario no se muestran.

Gestionar chats: El administrador puede revisar el historial de chats

de los ltimos 30 das para auditoria si es necesario. Los datos
sensibles de los usuarios no se muestran.
3.2. VISTA LGICA

3.2.1. OVERVIEW ARQUITECTURA

A continuacin se presenta el overview de la arquitectura que

se usar en el sistema.
Ilustracin 3. Overview arquitectura

Fuente: Creacin propia

La ampliacin de cada uno de los componentes se puede

encontrar en la siguiente seccin.
3.2.2. VISTA LGICA

A continuacin se presenta la vista lgica del sistema.

Ilustracin 4. Vista lgica

Fuente: Creacin propia

3.3. VISTA DE IMPLEMENTACIN

A continuacin se presenta el diagrama de implementacin del sistema.

Ilustracin 5. Vista de implementacin

Fuente: Creacin propia

3.4. VISTA DE DESPLIEGUE

A continuacin se presenta el diagrama fsico del sistema.

Ilustracin 6. Vista fsica

Fuente: Creacin propia

4. TACTICAS ARQUITECTURALES

Al momento de realizar el diseo arquitectural de un sistema, no es

suficiente especificar que atributos de calidad se van a manejar. Se
necesitan definir las tcticas arquitecturales para cada uno de los atributos
de calidad del sistema.

Estas tcticas son indispensables para realizar la arquitectura del sistema,

pues con base en estas, el diseo arquitectural cambia de manera
significativa. Las tcticas para cada atributo de calidad se presentan a
continuacin.

4.1. DISPONIBILIDAD

Las tcticas arquitecturales que se usarn para los escenarios de

disponibilidad son:
Tabla 2. Disponibilidad - Ping/Echo
DETECCIN DE FALLAS PING ECHO
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Determinar si un Se usaran mensajes El componente que El emisor antes de
componente est TCP/IP entre dos o se dispone a enviar enviar el mensaje con
en lnea antes de ms componentes un mensaje y el los datos a procesar,
enviar un mensaje. que requieran componente o enva un mensaje
garantizar la componentes que Ping por medio de la
disponibilidad deben recibir el red al receptor y si
mensaje. Se recibe un mensaje
emplean las Echo enva los datos,
funciones de si no lo recibe registra
configuracin de el error en el log de
Glassfish para la errores.
deteccin de fallas.
Fuente: Creacin propia

Tabla 3. Disponibilidad - Remocin desde el servicio

PREVENCIN DE FALLAS REMOCIN DESDE EL SERVICIO
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Reiniciar los Los administradores Aquel componente Los componentes que
componentes del podrn reiniciar los que se desee se van a reiniciar,
sistema componentes que reiniciar. deben sacar un
peridicamente. requieran un reinicio. componente copia que
se encargue de las
transacciones mientras
el original se reinicia.
Fuente: Creacin propia
4.2. ESCALABILIDAD

Las tcticas arquitecturales que se usarn para los escenarios de

escalabilidad son:
Tabla 4. Escalabilidad - Scale up
SCALE UP
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Aadir ms Se aplicar a los Se usarn los Los componentes
recursos a un componentes que componentes que interactan segn la
componente, como atiendan una mayor atiendan una mayor especificacin inicial
CPU, memoria cantidad de cantidad de de las vistas lgica,
RAM, capacidad de solicitudes y solicitudes y fsica y de
almacenamiento, requieran mayor requieran mayor implementacin.
entre otros. capacidad de capacidad de
cmputo. cmputo.
Fuente: Creacin propia

Tabla 5. Escalabilidad - Scale out

SCALE OUT
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Aadir ms Se aplicar a los Cuando se aplica Los componentes
maquinas que componentes que scale out se debe interactan segn la
compartan la carga atiendan una mayor usar el sistema en especificacin inicial
de los procesos. cantidad de general. Esto nos de las vistas lgica,
solicitudes y permite repartir el fsica y de
requieran mayor trfico y as implementacin.
capacidad de disminuir la carga
cmputo. en el hardware.
Fuente: Creacin propia

La implementacin de las tcticas descritas en esta seccin, se har

dependiendo del componente.

4.3. INTEGRACIN

Las tcticas arquitecturales que se usarn para los escenarios de

integracin son:
Tabla 6. Integracin - Minimizacin de interfaces
MINIMIZACIN DE INTERFACES
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Tener mayor Se realizar una Todos los Estos componentes
control sobre las revisin de las componentes interactan nicamente
interfaces pblicas funcionalidades que deben tener mediante protocolos
del sistema segn aparecen publicadas protocolos estndar estndar para
la metodologa en las interfaces para de comunicacin minimizar el nmero de
SOA [4]. evaluar si son entre ellos. interfaces en el
importantes para el sistema.
sistema.
Fuente: Creacin propia
 Tabla 7. Integracin - Conjunto limitado de protocolos de interaccin
CONJUNTO LIMITADO DE PROTOCOLOS DE INTERACCIN
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Tener mayor En cada interfaz se Se utilizar en Los componentes
control sobre los revisar el uso de todos los interactan segn la
protocolos de protocolos de componentes del especificacin inicial
comunicacin que comunicacin sistema. de las vistas lgica,
usaran los estndar (SOA [4], fsica y de
componentes HTTP, TCP). En caso implementacin.
de que la interfaz no
cuente con alguno de
estos protocolos, se
harn los cambios
respectivos para su
adecuacin.
Fuente: Creacin propia

Tabla 8. Integracin - Bajo acoplamiento y alta cohesin

BAJO ACOPLAMIENTO Y ALTA COHESIN
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Los componentes Se evaluar el Se utilizar en Los componentes
del sistema tendrn impacto de las todos los interactan segn la
las conexiones conexiones y componentes del especificacin inicial
necesarias para funcionalidades de sistema. de las vistas lgica,
ejecutar sus los componentes fsica y de
responsabilidades. relacionados del implementacin.
sistema segn los
elementos
funcionales
detallados que se
encuentren en el
sistema.
Fuente: Creacin propia

4.4. INTEROPERABILIDAD

Las tcticas arquitecturales que se usarn para los escenarios de

interoperabilidad son:
Tabla 9. Interoperabilidad - Minimizar la complejidad externa de los componentes
MINIMIZAR LA COMPLEJIDAD EXTERNA DE LOS COMPONENTES
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Controlar la Se analizar la Se utilizar en Los componentes
especificacin de especificacin de todos los interactan segn la
los componentes cada componente, su componentes del especificacin inicial
(Pre y post complejidad sistema que tengan de las vistas lgica,
condiciones, algortmica (notacin interaccin con fsica y de
interfaces, etc.) de orden) y las sistemas externos a implementacin.
funcionalidades que travs de
se proveen en las WebService.
interfaces.
Fuente: Creacin propia
 Tabla 10. Interoperabilidad - Establecer los nombres de los servicios de los componentes
ESTABLECER LOS NOMBRES DE LOS SERVICIOS DE LOS COMPONENTES
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Nombrar de forma Cada componente se Se utilizar en Los componentes
adecuada los nombrar de acuerdo todos los interactan segn la
componentes del a la responsabilidad y componentes del especificacin inicial
sistema. funcionalidades que sistema. de las vistas lgica,
le sean asignadas. fsica y de
implementacin.
Fuente: Creacin propia

4.5. MANTENIMIENTO

Las tcticas arquitecturales que se usarn para los escenarios de

mantenimiento son:
Tabla 11. Mantenimiento - Protocolos de comunicacin adecuados
PROTOCOLOS DE COMUNICACIN ADECUADOS
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Manejar protocolos En las conexiones Los componentes Los componentes
de comunicacin entre componentes que se emplearn interactan segn la
estndar para que se emplearn sern los especificacin inicial
estos no sean un protocolos de relacionados con de las vistas lgica,
inconveniente al comunicacin otros componentes fsica y de
momento de estndar (SOA [4], a travs de implementacin.
conectar nuevos HTTP, TCP). conexiones
componentes externas
dependiendo de las
necesidades del
sistema.
Fuente: Creacin propia

Tabla 12. Mantenimiento - Diseo coherente de los componentes

DISEO COHERENTE DE LOS COMPONENTES
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Los componentes Cada componente Se realizar para Los componentes
no debern ser evaluado segn todos los interactan segn la
presentar sus componentes del especificacin inicial
ambigedades en responsabilidades y sistema. de las vistas lgica,
cada uno de los funcionalidades fsica y de
diagramas que los desde la arquitectura implementacin.
representan de del sistema.
forma abstracta.
Fuente: Creacin propia
 Tabla 13. Mantenimiento - Cdigo fuente legible y manejable
CDIGO FUENTE LEGIBLE Y MANEJABLE
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
El cdigo fuente del Se emplear el Se emplear para Los componentes
sistema debe ser estndar JAVADOC. todos los interactan segn la
claro y componentes de especificacin inicial
correctamente software del de las vistas lgica,
separado en sistema. fsica y de
paquetes. implementacin.
Fuente: Creacin propia

Tabla 14. Mantenimiento - Documentacin clara y completa

DOCUMENTACIN CLARA Y COMPLETA
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Tener una La arquitectura ser Se documentarn Los componentes
documentacin documentada todos los interactan segn la
clara y completa de empleando la plantilla componentes especificacin inicial
todos los SAD con la arquitecturalmente de las vistas lgica,
componentes del metodologa de vistas significantes del fsica y de
sistema. 4+1 y empleando sistema. implementacin.
escenarios de
calidad.
Fuente: Creacin propia

4.6. PORTABILIDAD

Las tcticas arquitecturales que se usarn para los escenarios de

portabilidad son:
Tabla 15. Portabilidad - Mquinas virtuales
MAQUINAS VIRTUALES
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Se tendrn en Segn la Se aplicar para Los componentes
cuenta las implementacin todos los interactan segn la
mquinas virtuales tecnolgica que se componentes de especificacin inicial
que se usarn para realice para cada software del de las vistas lgica,
cada dispositivo a componente del sistema. El sistema fsica y de
lo largo del sistema se emplear es portable a travs implementacin.
sistema. la mquina virtual de del framework Java
JAVA para el EE y se despliega
despliegue en en las mquinas
hardware virtuales de Java
heterogneo. segn la
especificacin de
Oracle.
Fuente: Creacin propia
 Tabla 16. Portabilidad - Uso de interfaces estandar entre componentes
USO DE INTERFACES ESTANDAR ENTRE COMPONENTES
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Se controlar el Las interfaces Se aplicar para Los componentes
uso de interfaces empleadas en los todos los interactan segn la
estndares entre componentes sern componentes de especificacin inicial
los componentes, elaboradas en la software del de las vistas lgica,
para mejorar la misma tecnologa de sistema que fsica y de
comunicacin entre comunicacin. requieran implementacin.
las diferentes interaccin con
plataformas. otros componentes
o sistemas
externos. Las
interfaces externas
estndar que se
emplearn sern
WebService en
XML usando
WSDL.
Fuente: Creacin propia

4.7. RENDIMIENTO

Las tcticas arquitecturales que se usarn para los escenarios de

rendimiento son:
Tabla 17. Rendimiento - Incremento de eficiencia computacional
DEMANDA DE RECURSOS INCREMENTO DE EFICIENCIA COMPUTACIONAL
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Aumentar la Dependiendo del Cualquier N/A
capacidad de proceso que se est componente que
procesamiento de ejecutando, se necesite muchos
los recursos. dispondrn de dos o recursos para
ms procesadores procesar la
para su informacin.
procesamiento.
Fuente: Creacin propia

Tabla 18. Rendimiento - Reducir la sobrecarga computacional

DEMANDA DE RECURSOS REDUCIR LA SOBRECARGA COMPUTACIONAL
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Implementar la Desde el diseo, los Todos los Como los
comunicacin entre componentes sern componentes que componentes que
los componentes conectados entre s, reciban altas reciben altas
de una manera dependiendo de sus peticiones de peticiones de
adecuada para que funcionalidades. As procesamiento por procesamiento estn
no se presenten mismo, se parte de otros replicados, los
cuellos de botella. determinara si un componentes. La componentes
componente ser sobrecarga se interactan
replicado muchas reduce a travs de normalmente por
veces para que las los EJB medio de envo de
peticiones no se @Stateless. mensajes.
queden en una cola
sino se procesen de
manera rpida.
Fuente: Creacin propia
 Tabla 19. Rendimiento - Concurrencia
ADMINISTRACIN DE RECURSOS CONCURRENCIA
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Los procesos se Todos los procesos Cualquier Estos componentes
ejecutaran en del sistema sern componente que necesitan capacidad
varios distribuidos, es decir, realice procesos de de procesamiento e
procesadores. se ejecutaran en alta complejidad interactuaran
diferentes que requieran directamente con el
procesadores. mayor procesador.
procesamiento.
Para esto se
emplear el Pool de
instancias de
objetos de
Glassfish.
Fuente: Creacin propia

Tabla 20. Rendimiento - Mantener mltiples copias

ADMINISTRACIN DE RECURSOS MANTENER MULTIPLES COPIAS
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Hacer copias de los Se tendrn varias Cualquier Al ser un proceso
datos crticos del copias dentro de los componente que interno del
sistema para que componentes de los sea muy componente, este
los procesos datos que son demandado por tendr varias copias de
accedan ms consultados con ms otros componentes. los datos que se
rpido a estos. frecuencia. Las copias de los necesiten acceder para
componentes se que cuando lleguen las
realizan por las peticiones, se puedan
funciones de leer con ms facilidad.
Clster de
Glassfish.
Fuente: Creacin propia

4.8. SEGURIDAD

Las tcticas arquitecturales que se usarn para los escenarios de

seguridad son:
Tabla 21. Seguridad - Usuarios autenticados
RESISTENCIA A ATAQUES USUARIOS AUTENTICADOS
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Usar registro de Al momento de Se usa el Datos Este componente
usuarios con un ID acceder al sistema, el Manager que es el interacta
y una contrasea usuario deber llenar encargado de directamente con la
(Los usuarios no un formulario con los revisar los datos base de datos
autenticados solo campos usuario y entrantes y dependiendo de las
podrn hacer contrasea. Estos salientes de la base entradas del usuario.
peticiones de deben ser correctos de datos.
lectura). para acceder a las
funcionalidades
Fuente: Creacin propia
 Tabla 22. Seguridad - Usuarios autorizados
RESISTENCIA A ATAQUES USUARIOS AUTORIZADOS
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Se tendrn Los usuarios activos Cualquier Los componentes que
permisos tendrn una variable componente que requieran validar los
especiales para activa que define si requiera validar los permisos de un
cada tipo de son administradores permisos de un usuario, deben
usuario o no. Los usuario registrado. consultar los datos del
(comprador, componentes que Se emplean los mismo para saber si es
vendedor, requieran permisos mtodos nativos de annimo, usuario o
administrador), especiales pueden autorizacin de administrador.
para controlar las consultar esta Java EE 6.
partes del sistema variable para
donde puede o no determinar si da o no
ingresar acceso a las
funcionalidades
ofrecidas.
Fuente: Creacin propia

Tabla 23. Seguridad - Integridad de datos

RESISTENCIA A ATAQUES INTEGRIDAD DE DATOS
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Usar Hash para Antes del envo de Cualquier El emisor genera el
verificar la los datos crticos, se componente que cdigo Hash y lo enva
integridad de los aplicara Hash sobre enve datos crticos al receptor. Seguido a
datos recibidos por los datos y el en el sistema. Se esto, el emisor enva el
un componente. resultado se enva emplearn sumas mensaje y cuando el
antes de enviar los de verificacin receptor lo recibe, lo
datos. dentro de los compara con la cadena
aspectos Hash recibida para
transversales de los verificar la integridad
EJB. de los datos.
Fuente: Creacin propia

Tabla 24. Seguridad - Limitacin de exposicin

RESISTENCIA A ATAQUES LIMITACIN DE EXPOSICIN
Qu componentes Cmo interactan
En qu consiste? Cmo se aplicar?
deben usarse? dichos componentes?
Minimizar los En el momento del El Datos Manager Estos componentes
puntos de entrada diseo del sistema, es el componente presentan pocas
de los los componentes principal de acceso entradas para
componentes crticos del sistema a los datos a la conexin con otros
crticos del sistema. tendrn nicamente base de datos componentes lo que
los puntos de entrada limita la exposicin de
necesarios. los mismos.
Fuente: Creacin propia