Arquitecturas de una aplicación
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Arquitecturas de una aplicación

on

  • 285 views

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

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á

Statistics

Views

Total Views
285
Views on SlideShare
285
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Arquitecturas de una aplicación Presentation Transcript

  • 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 competitivaJesú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ón01.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.06 Arquitectura orientada a Dominio (DDD) (II) Arquitecturas de una aplicación 15
  • 16. 02 Tipos de Estilos Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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 Arquitecturales02.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ónJesús Cáceres Tellojesus.caceres@uah.esDepartamento de Ciencias de la ComputaciónEscuela Universitaria PolitécnicaCampus de Alcaláhttp://www.cc.uah.es