Arquitecturas de una aplicación

Departamento de Ciencias de la Computación

Arquitecturas de una
aplicación

Gestión I+D+i: Sistema de vigilancia
tecnológica e inteligencia competitiva

Jesús Cáceres Tello

Índice I
01 Conceptos iniciales
01.01 Vigilancia Tecnológica
01.02 Inteligencia competitiva
01.03. La norma 166006
02 Requisitos del Sistema de Vigilancia
02.01 Tipos de Requisitos
02.02 Requisitos Generales
02.03 Requisitos de Documentación
02.04 Requisitos de confidencialidad, legalidad y aspectos
éticos
03 Responsabilidades de la Dirección
03.01 Compromiso
03.02 Política de VT/IC
03.03 Planificación y objetivos

Arquitecturas de una aplicación
03.04 Responsabilidad, autoridad y comunicación
03.05 Revisión
04 Gestión de Recursos
04.01 Provisión de recursos
04.02 Recursos humanos
04.03 Recursos materiales e infraestructura

2

01 Introducción
01.01 Estilos arquitecturales

 Son indicaciones abstractas de cómo dividir/organizar
un sistema y de cómo se realiza en proceso de
interacción entre ellas (No son patrones de diseño)
 Son herramientas básicas de un arquitecto a la hora de
dar forma a la arquitectura de una aplicación
 Se organizan en torno al aspecto de la aplicación:
 Comunicación
 Despliegue
 Dominio

 Interacción
 Estructura
 Lo normal es que una arquitectura se base en varios
estilos arquitecturales

3

02 Tipos de Estilos Arquitecturales
02.01 Cliente/Servidor (I)

 El estilo cliente/servidor define una relación entre dos
aplicaciones en las cuales una de ellas (cliente) envía
peticiones a la otra (servidor fuente de datos)

 Características:

 Es para sistemas distribuidos
 Divide el sistema en dos aplciaciones
 Describe la relación cliente/servidor (uno envía peticiones y el otro
envía respuestas)
 Puede usar un amplio rango de protocolos y formatos de datos
para comunicar la información (SOAP, HTTP, HTTPS, XML,…)
4

02.01 Cliente/Servidor (II)
 Claves:
 El cliente realiza peticiones y espera a la recepción de la respuesta
para posteriormente procesarla
 El cliente se suele conectar a un solo servidor al mismo tiempo
 Si existe interacción con el usuario, ésta se realiza en el lado del
cliente (interfaz gráfica)
 El servidor no realiza ninguna petición al cliente
 El servidor envía los datos en repuesta a las peticiones realizadas
 El proceso en el servidor sería: autentificación y verificación del
usuario, procesamiento de la petición y envío de resultados
 Beneficios:

 Más seguridad
 Acceso centralizado a los datos
 Facilidad en el mantenimiento (roles)
 Cuándo usarlo:
 Cuando se soporte a varios clientes
 Cuando la aplicación se ejecute en una red (LAN, WAN)
 Implementación de procesos de negocio de uso en toda la Org.
5
 Diferentes roles

02.02 Basado en componentes (I)
 Describe un acercamiento al diseño de sistemas como un
conjunto de componentes que exponen interfaces bien
definidas y de colaboración conjunta para la resolución de
problemas.

 Diseño de aplicaciones a partir de componentes individuales
 Da prioridad a la descomposición del sistema en componentes:
métodos, eventos y propiedades

6

02.02 Basado en componentes (I)
 Claves:
 Diseño de componentes orientado a la reutilización en distintas
aplicaciones (cuando se pueda), independientes.
 Diseñados para diferentes entornos y contextos, se le debe pasar
toda la información, no debe contener ninguna información
 Puede existir herencia en los componentes y encapsulación
 Beneficios:
 Facilidad en el despliegue
 Reducción de costes, se pueden utilizar componentes de terceros
 Reusabilidad por su independencia del contexto
 Reducción de la complejidad: contenedores de componentes

(activación, gestión del ciclo de vida, etc.)
 Cuándo usarlo:
 Facilidad para conseguir esos componentes
 Ejecución de aplicaciones con pocos o ningún dato de entrada
 Combinación de componentes escritos en diferentes lenguajes
 Actualización de componentes de forma sencilla.
7

02.03 En Capas (N-Layer) (I)
 Se basa en una distribución jerárquica de los roles y las
responsabilidades para proporcionar una división efectiva de
los problemas a resolver. Los roles indican el tipo y la forma
de la interacción con otras capas , y las responsabilidades la
funcionalidad que implementan

 La mayoría de las interacciones ocurren sólo entre las capas
vecinas
 Las capas pueden estar distribuidas en diferentes máquinas
 Comunicación entre capas a través de interfaces bien conocidas
 Herencia entre capas de distinto nivel
 Separación clara de las funcionalidades de cada capa
8

02.03 En Capas (N-Layer) (II)
 Claves:
 Cada capa contiene la funcionalidad relacionada solo con las
tareas de esa capa
 No existe dependencia de las capas inferiores con las superiores
 La comunicación entre capas está basada en una abstracción que
permite una acoplamiento entre capas
 Beneficios:
 Alto rendimiento basado en la distribución de capas en distintos
niveles físicos, escalabilidad y tolerancia a fallos.
 Testeabilidad ya que cada capa tiene una interfaz bien definida
sobre la que se pueden realizar pruebas
 Independencia del hardware, no hay despliegue y no hay

dependencia con interfaces externas.
 Cuándo usarlo:
 Si se tienen implementaciones de capas ya construidas
(reusabilidad)
 Aplicaciones complejas con distintos equipos de desarrollo.
 La aplicación debe soportar distintos tipos de clientes y distintos
dispositivos
 Idónea cuando se quieran implementar reglas y procesos de 9

negocio complejos y/o configurables

02.04 Presentación Desacoplada (I)
 Indica cómo debe realizarse el manejo de las acciones del
usuario, la manipulación de la interfaz y los datos de la
aplicación. Este estilo separa los componentes de la interfaz
del flujo de datos y de la manipulación.


 Muy conveniente cuando se diseñan aplicaciones basadas en
patrones de diseño.
 Separación de la lógica y de la presentación de los datos
 Permite trabajo paralelo entre diseñadores y desarrolladores
 Permite mejor testeo ya que se pueden testear comportamientos
individualmente

10

02.04 Presentación Desacoplada (II)
 Claves:
 Puede separar el procesamiento de la interfaz en distintos roles
 Permiten la construcción de mocks para el testeo
 Utiliza eventos de notificación para la vista cuando ha habido
modificación de datos.
 El controlador maneja los eventos disparados desde los controles
de usuario en la vista
 Beneficios:
 Testeabilidad (moks)
 Reusabilidad, los controladores pueden ser utilizados por otras
vistas y las vistas por otros controladores.
 Cuándo usarlo:

 Cuando se quiera separar la creación del interfaz de la lógica que
la maneja
 La interfaz no contenga ningún código de procesamiento de
eventos
 El código de procesamiento de la interfaz no implementa ninguna
lógica de negocio.

11

02.05 Presentación Desacoplada N-Niveles (N-Tier) (I)
 Define la separación de la funcionalidad en diferentes
segmentos o niveles físicos. Es similar al estilo N-Capas pero
sitúa cada segmento en una máquina distinta. En este caso
hablamos de niveles físicos (Tiers)


 Separación de niveles físicos (Servidores normalmente) por
distintas razones, escalabilidad, seguridad, o simplemente por
necesidad

12

02.05 Presentación Desacoplada N-Niveles (N-Tier) (II)
 Claves:
 Es un estilo para definir el despliegue de las capas de la aplicación
 Descomposición funcional de las aplicaciones, componentes de
servicio y su despliegue para múltiples mejoras (escalabilidad,
disponibilidad, rendimiento, manejabilidad y uso de recursos)
 Independencia de niveles menos en el inmediatamente inferior
 Tiene al menos 3 niveles lógicos separadas en distintos servidores
 Despliegue de una capa en un nivel si uno o más servicios
dependen de la funcionalidad expuesta por dicha capa.
 Beneficios:
 Mantenibilidad, independencia de los niveles (actualizaciones)
 Escalabilidad, los niveles están basados en el despliegue de capas

 Disponibilidad, tolerancia a fallos de los distintos niveles
 Cuándo usarlo:
 Cuando los requisitos de procesamiento o de seguridad de las
capas son diferentes
 Compartir la lógica de negocio entre varias aplicaciones
 Disponibilidad de hardware para desplegar el número necesario de
servidores en cada nivel.
13

02.06 Arquitectura orientada a Dominio (DDD) (I)
 Es una forma de afrontar los proyectos a nivel equipo de
desarrollo centrándose en lo que el cliente solicita.
 Contextualiza el problema a resolver dentro de un dominio. El
conjunto de clases y operaciones asociadas deben estar
diseñadas para solucionar el problema con independencia de
cualquier otro aspecto del sistema, como la persistencia,
servicios web, etc.
 Utiliza patrones y otras arquitecturas para el diseño de una
aplicación:
 Arquitectura N-Capas

 Patrones de Diseño
 Repository
 Entity
 Aggregate
 Value-Object
 Unit Of Work
 Service
 Considera de vital importancia el desacoplamiento entre
componentes 14

02.06 Arquitectura orientada a Dominio (DDD) (II)

15

02.06 Arquitectura orientada a Dominio (DDD) (III)

 Claves:
 Se debe tener un buen entendimiento del Domino de Negocio que
se desea modelar.
 Contacto permanente del equipo de desarrollo con los expertos del
dominio.
 Todo el equipo debe manejar el mismo lenguaje sobre el Dominio
de Negocio (Lenguaje Ubicuo)
 El core del software es el Modelo de Dominio carente de
ambiguedades
 Debe aplicarse únicamente a dominios complejos donde el modelo

y los procesos lingüísticos proporcionen claros beneficios en la
comunicación de la información.
 La complejidad arquitectural es mucho mayor aunque su
mantenibilidad y desacoplamiento entre componentes es mucho
mayor.

16

02.06 Arquitectura orientada a Dominio (DDD) (IV)

 Mejor Testing: facilita el Testing y el Mocking debido al
desacoplamiento de objetos.

 Cuándo usarlo:
 En aplicaciones complejas con mucha lógica de negocio con
mejora de la comunicación y minimización de malos entendidos
 En escenarios empresariales de gran tamaño difíciles de manejar
con otras técnicas.

17

02.07 Orientación a Objetos (I)
 Define el sistema como un conjunto de objetos que cooperan
entre sí en lugar de cómo un conjunto de procedimientos. Los
objetos son discretos, independientes y poco acoplados, se
comunican mediante interfaces y permiten enviar y recibir
mensajes.

 Indicado para diseñar aplicaciones basadas en un número de
unidades lógicas y código reusable.

 Describe el uso de objetos que contienen los datos y el
comportamiento para trabajar con esos datos y además tienen un
rol o responsabilidad distinta
 Incide en la reutilización a través de la encapsulación, la
modularidad, el polimorfismo y la herencia
 Contrasta con el acercamiento procedimental (secuencia definida
de tareas y acciones)
18

02.07 Orientación a Objetos (II)
 Claves:
 Permite reducir operaciones complejas mediante generalizaciones
 Un objeto puede estar formado por otros objetos con visibilidad o
no respecto a otras clases
 Existe la herencia entre objetos heredando sus funcionalidades o
redefiniéndolas para implementar un nuevo comportamiento
 La herencia facilita el mantenimiento y actualización ya que los
cambios se propagan automáticamente a todos los objetos
herederos
 Beneficios:
 Mayor comprensión ya que los objetos son mucho más cercanos al
mundo real

 Mejor Reusabilidad apoyado por el polimorfismo y la abstracción
 Testeabilidad gracias a la encapsulación de los objetos
 Extensibilidad gracias a la encapsulación, polimorfismo y
abstracción
 Cuándo usarlo:
 Modelo basado en objetos reales y sus acciones
 Ya se dispone de los objetos que encajan en el diseño
19
 Encapsulación de lógica y datos juntos de forma transparente

02.08 Orientación a Servicios (SOA) (I)
 Permite a una aplicación ofrecer su funcionalidad como un
conjunto de servicios para que sean consumidos. Los servicios
usan interfaces estándar que pueden ser invocadas,
publicadas y descubiertas. Proporcionan un esquema basado
en mensajes

 Interacción con el servicio muy desacoplada
 Puede empaquetar procesos de negocio como servicios
 Los clientes y otros servicios pueden acceder a servicios locales
corriendo en el mismo nivel.
 Los clientes y otros servicios acceden a los servicios remotos a
través de la red
 Puede usar un amplio rango de protocolos y formatos de datos 20

02.08 Orientación a Servicios (SOA) (II)
 Claves:
 Los servicios son autónomos
 Los servicios pueden estar situados en cualquier nodo de una red local o
remota mientras se soporten los protocolos de comunicación necesarios
 Los servicios comparten esquemas y contratos para comunicarse, no clases
 La compatibilidad se basa en factores como el mecanismo de transporte, el
protocolo y la seguridad
 Beneficios:
 Alineamiento con el dominio de la empresa, reutilización de servicios =
aumento de oportunidades tecnológicas y de negocio y reducción de costes.
 Abstracción ya que los servicios son autónomos
 Descubrimiento, mediante descripciones estándar (wsdl)
 Cuándo usarlo:

 Construcción de aplicaciones con múltiples servicios y una interfaz única.
 Creación de aplicaciones en la nube
 Comunicación basada en mensajes
 Funcionalidad con independencia de la plataforma
 Necesidad de establecer servicios federados, p.e. con autenticación
 Exposición de servicios con independencia del conocimiento por parte del
cliente de su interfaz
 Adecuado para escenarios de interoperabilidad e integración.
21

03 Referencias

 C. de la Torre, U. Zorrilla, J. Calvarro, M.A. Ramos. “Guía de
Arquitecturas N-Capas” (pp. 9-60). Cap. Estilos
arquitecturales. Ed. Frasis Press, 2010.
http://msdn.microsoft.com/es-es/architecture/default.aspx

22

Gracias por su atención
Jesús Cáceres Tello
jesus.caceres@uah.es

Departamento de Ciencias de la Computación
Escuela Universitaria Politécnica
Campus de Alcalá
http://www.cc.uah.es

Arquitecturas de una aplicación

Más contenido relacionado

La actualidad más candente (20)

Destacado (6)

Similar a Arquitecturas de una aplicación (20)

Último (20)

Arquitecturas de una aplicación