Gestión I+D+i: sistema de vigilancia tecnológicas e inteligencia competitiva. Asignatura Desarrollo con Tecnologías Emergentes, Grado de Ingeniería Informática, Escuela Técnica Superior de Informática, Universidad de Alcalá
KELA Presentacion Costa Rica 2024 - evento Protégeles
Arquitecturas de una aplicación
1. 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
2. Í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
3. 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
Arquitecturas de una aplicación
Interacción
Estructura
Lo normal es que una arquitectura se base en varios
estilos arquitecturales
3
4. 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:
Arquitecturas de una aplicación
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
5. 02 Tipos de Estilos Arquitecturales
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:
Arquitecturas de una aplicación
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
6. 02 Tipos de Estilos Arquitecturales
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.
Arquitecturas de una aplicación
Características:
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
7. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
(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
8. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
Características:
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
9. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
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
10. 02 Tipos de Estilos Arquitecturales
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.
Características:
Arquitecturas de una aplicació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
11. 02 Tipos de Estilos Arquitecturales
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:
Arquitecturas de una aplicación
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
12. 02 Tipos de Estilos Arquitecturales
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)
Características:
Arquitecturas de una aplicación
Separación de niveles físicos (Servidores normalmente) por
distintas razones, escalabilidad, seguridad, o simplemente por
necesidad
12
13. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
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
14. 02 Tipos de Estilos Arquitecturales
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.
Características:
Utiliza patrones y otras arquitecturas para el diseño de una
aplicación:
Arquitectura N-Capas
Arquitecturas de una aplicación
Patrones de Diseño
Repository
Entity
Aggregate
Value-Object
Unit Of Work
Service
Considera de vital importancia el desacoplamiento entre
componentes 14
15. 02 Tipos de Estilos Arquitecturales
02.06 Arquitectura orientada a Dominio (DDD) (II)
Arquitecturas de una aplicación
15
16. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
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
17. 02 Tipos de Estilos Arquitecturales
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.
Arquitecturas de una aplicación
17
18. 02 Tipos de Estilos Arquitecturales
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.
Características:
Indicado para diseñar aplicaciones basadas en un número de
unidades lógicas y código reusable.
Arquitecturas de una aplicación
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
19. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
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
20. 02 Tipos de Estilos Arquitecturales
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
Arquitecturas de una aplicación
Características:
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
21. 02 Tipos de Estilos Arquitecturales
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:
Arquitecturas de una aplicación
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
22. 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
Arquitecturas de una aplicación
22
23. 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