Arquitecturas de una aplicación

23
Departamento de Ciencias de la Computación Gestión I+D+i: Sistema de vigilancia tecnológica e inteligencia competitiva Arquitecturas de una aplicación Jesús Cáceres Tello

description

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á

Transcript of Arquitecturas de una aplicación

Page 1: Arquitecturas de una aplicación

Departamento de Ciencias de la Computación

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

Arquitecturas de una aplicación

Jesús Cáceres Tello

Page 2: Arquitecturas de una aplicación

2

Arqu

itect

uras

de

una

aplic

ació

n

Índice

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 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

I

Page 3: Arquitecturas de una aplicación

3

Arqu

itect

uras

de

una

aplic

ació

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

01 Introducción

Page 4: Arquitecturas de una aplicación

4

Arqu

itect

uras

de

una

aplic

ació

n

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,…)

02 Tipos de Estilos Arquitecturales

Page 5: Arquitecturas de una aplicación

5

Arqu

itect

uras

de

una

aplic

ació

n

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. Diferentes roles

02 Tipos de Estilos Arquitecturales

Page 6: Arquitecturas de una aplicación

6

Arqu

itect

uras

de

una

aplic

ació

n

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.

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

02 Tipos de Estilos Arquitecturales

Page 7: Arquitecturas de una aplicación

7

Arqu

itect

uras

de

una

aplic

ació

n

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.

02 Tipos de Estilos Arquitecturales

Page 8: Arquitecturas de una aplicación

8

Arqu

itect

uras

de

una

aplic

ació

n

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

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

02 Tipos de Estilos Arquitecturales

Page 9: Arquitecturas de una aplicación

9

Arqu

itect

uras

de

una

aplic

ació

n

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

negocio complejos y/o configurables

02 Tipos de Estilos Arquitecturales

Page 10: Arquitecturas de una aplicación

10

Arqu

itect

uras

de

una

aplic

ació

n

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: 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

02 Tipos de Estilos Arquitecturales

Page 11: Arquitecturas de una aplicación

11

Arqu

itect

uras

de

una

aplic

ació

n

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.

02 Tipos de Estilos Arquitecturales

Page 12: Arquitecturas de una aplicación

12

Arqu

itect

uras

de

una

aplic

ació

n

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: Separación de niveles físicos (Servidores normalmente) por

distintas razones, escalabilidad, seguridad, o simplemente por necesidad

02 Tipos de Estilos Arquitecturales

Page 13: Arquitecturas de una aplicación

13

Arqu

itect

uras

de

una

aplic

ació

n

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.

02 Tipos de Estilos Arquitecturales

Page 14: Arquitecturas de una aplicación

14

Arqu

itect

uras

de

una

aplic

ació

n

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 Patrones de Diseño

Repository Entity Aggregate Value-Object Unit Of Work Service

Considera de vital importancia el desacoplamiento entre componentes

02 Tipos de Estilos Arquitecturales

Page 15: Arquitecturas de una aplicación

15

Arqu

itect

uras

de

una

aplic

ació

n

02.06 Arquitectura orientada a Dominio (DDD) (II) 02 Tipos de Estilos Arquitecturales

Page 16: Arquitecturas de una aplicación

16

Arqu

itect

uras

de

una

aplic

ació

n

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.

02 Tipos de Estilos Arquitecturales

Page 17: Arquitecturas de una aplicación

17

Arqu

itect

uras

de

una

aplic

ació

n

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.

02 Tipos de Estilos Arquitecturales

Page 18: Arquitecturas de una aplicación

18

Arqu

itect

uras

de

una

aplic

ació

n

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. 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)

02 Tipos de Estilos Arquitecturales

Page 19: Arquitecturas de una aplicación

19

Arqu

itect

uras

de

una

aplic

ació

n

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 Encapsulación de lógica y datos juntos de forma transparente

02 Tipos de Estilos Arquitecturales

Page 20: Arquitecturas de una aplicación

20

Arqu

itect

uras

de

una

aplic

ació

n

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

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

02 Tipos de Estilos Arquitecturales

Page 21: Arquitecturas de una aplicación

21

Arqu

itect

uras

de

una

aplic

ació

n

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.

02 Tipos de Estilos Arquitecturales

Page 22: Arquitecturas de una aplicación

22

Arqu

itect

uras

de

una

aplic

ació

n

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

03 Referencias

Page 23: Arquitecturas de una aplicación

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

Gracias por su atención Jesús Cáceres Tello [email protected]