Tema 1: Patrones Arquitectónicos

24
Departamento de Lenguajes y Sistemas Informáticos escuela técnica superior de ingeniería informática Ingeniería del Software de Gestión III Tema 1: Patrones Arquitectónicos

Transcript of Tema 1: Patrones Arquitectónicos

Page 1: Tema 1: Patrones Arquitectónicos

Departamento deLenguajes y Sistemas Informáticos

escuela técnica superiorde ingeniería informática

Ingeniería del Software de Gestión III

Tema 1: Patrones Arquitectónicos

Page 2: Tema 1: Patrones Arquitectónicos

Ejemplo de otro dominio

Diseño de la arquitectura Implementación de la arquitectura

Page 3: Tema 1: Patrones Arquitectónicos

Índice

• Definiciones• ¿Qué es un SID?• Aplicación de ejemplo• Diseño de un SID• Arquitectura de un SID• Patrón MVC• Arquitectura SOA• Bibliografía

Page 4: Tema 1: Patrones Arquitectónicos

Definiciones

"Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled."– Eoin Woods

En [Buschmann96] se definen tres tipos de patrones• Patrones arquitectónicos sobre aspectos

fundamentales de la estructura de un sistema software. Especifican un conjunto predefinido de subsistemas con sus responsabilidades y una serie de recomendaciones para organizar los distintos componentes

• Patrones de diseño sobre aspectos relacionados con el diseño de los subsistemas. Por tanto se centran en aspectos más específicos

• Idiom es un patrón de bajo nivel específico de un lenguaje de programación o entrono de desarrollo

Page 5: Tema 1: Patrones Arquitectónicos

¿Qué es un SID?

Dominio del problema

Visitante Administrador

Cliente

Vendedor

SID: Sistema de Información Distribuido

Page 6: Tema 1: Patrones Arquitectónicos

Aplicación de ejemplo

Cliente Sistema

Identificarse

Consultar Productos

Añadir Productos

Eliminar Productos

Confirmar Compra

USVirtual

Page 7: Tema 1: Patrones Arquitectónicos

Aplicación de ejemplo

Cliente

Consultar Productos

Añadir Productos

Eliminar Productos

Confirmar Compra

Visualizar Carrito

Añadir

Seguir Compra

Acabar Compra

Eliminar

Page 8: Tema 1: Patrones Arquitectónicos

Diseño de un SID

• Se pueden distinguir varios aspectos comunes en el diseño de un SID• Diseño en capas

• Diseño arriba-abajo (“top-down”)

• Diseño abajo-arriba (“bottom-up”)

Diseño: Concepción original de un objeto u obra destinados a la producción en serie. Diseño gráfico, de modas, industrial

Design: a mental project or scheme in which means to an end are laid down

Page 9: Tema 1: Patrones Arquitectónicos

Diseño en Capas de un SID

Cliente

Capa de Presentación

Capa de Lógica de aplicación

Capa de Acceso a

Datos /Recursos

Sis

tem

a d

e I

nfo

rmació

n

Sólo son conceptuales: No tienen por qué corresponderse con la estructura de la implementación.

También conocida como vista lógica de la arquitectura.

Capa (Layer), Nivel (Tier)

Page 10: Tema 1: Patrones Arquitectónicos

Capa de presentación

Cliente

Presentación

SID

Responsable de: (1) presentar información e (2) interactuar con la capa inferior externas

A veces también se le llama CLIENTE pero da lugar a confusiones

¿Cuál es la diferencia entre cliente y la capa de presentación?

Page 11: Tema 1: Patrones Arquitectónicos

Capa de lógica de aplicación

Responsable de: implementar las operaciones solicitadas por los clientes a través de la capa de presentación.

Ej: el componente encargado de ver si un cliente está o no logado

Dependiendo de la complejidad y de la técnica de implementación empleada, también se le conoce como: proceso/lógica/reglas de negocio o simplemente servidor

Presentación

Lógica de aplicación

Datos/Recursos

Page 12: Tema 1: Patrones Arquitectónicos

Capa de acceso a datos/recursos

Responsable de: gestionar todos los elementos de información del SID; ficheros planos, XML, SGBD, etcétera

En algunas arquitecturas se considera como parte integrante de esta capa aquellos sistemas externos que proporcionan información. Es el eslabón necesario para componer SID a partir de otros SID.

Denominar a esta capa como ‘capa de datos’ no es del todo riguroso, ¿por qué?

Presentación

Lógica de aplicación

Datos/Recursos ¿Qué otros elementos pueden

proporcionar información?

También conocida como capa de gestión de recursos

Page 13: Tema 1: Patrones Arquitectónicos

Diseño arriba-abajo (“top-down”)

• Definir la funcionalidad del sistema desde el punto de vista del cliente

• Ir propagando por las capas según las necesidades identificadas en las capas anteriores

• Ventajas: • Desde el principio se tienen

claras las funcionalidades y se dirige el desarrollo sobre ellas

• Desventaja:• Sólo es posible aplicarlo a

sistemas desarrollados desde cero

• Los componentes por lo general son fuertemente acoplados pues se usan en entornos homogéneos.

C l i e n t e

C a p a d e P r e s e n t a c i ó n

C a p a d e L ó g i c a d e a p l i c a c i ó n

C a p a d e A c c e s o a

D a t o s / R e c u r s o s

Sis

tem

a d

e I

nfo

rma

ció

n

Page 14: Tema 1: Patrones Arquitectónicos

Diseño abajo-arriba (“bottom-up”)

• Suele surgir por necesidad más que por elección

• Muchos de los sistemas de hoy en día se basan en la integración de productos existentes (legancy systems: sistemas heredados)

• Sistema heredado: aquel que es utilizado en un contexto distinto del que en principio fue concebido. La mayoría de SID se convierten en sistemas heredados

• Si tenemos que integrar sistemas heredados no podemos seguir un diseño arriba-abajo

• ¿Definimos por tanto la funcionalidad del sistema al final?

C l i e n t e

C a p a d e P r e s e n t a c i ó n

C a p a d e L ó g i c a d e a p l i c a c i ó n

C a p a d e A c c e s o a

D a t o s / R e c u r s o s

Sis

tem

a d

e I

nfo

rma

ció

n

Page 15: Tema 1: Patrones Arquitectónicos

Diseño abajo-arriba (“bottom-up”)

• Definir la funcionalidad desde el punto de vista del cliente

• Examinar recursos existentes y la funcionalidad que ofrecen

• Encapsular la funcionalidad existente

• Adaptar la salida de la aplicación a las necesidades del cliente

• Ventaja: • Los componentes por lo

general son poco acoplados y pueden ser reutilizados

• Desventaja:• Viene impuesto por

necesidades existentes

C l i e n t e

C a p a d e P r e s e n t a c i ó n

C a p a d e L ó g i c a d e a p l i c a c i ó n

C a p a d e A c c e s o a

D a t o s / R e c u r s o s

Sis

tem

a d

e I

nfo

rma

ció

n

Page 16: Tema 1: Patrones Arquitectónicos

Arquitectura de un SID

• A la hora de implementar un SID las capas (layer) conceptuales pueden quedarse en uno o más niveles (tier)

• Existen 4 tipos básicos de arquitecturas: 1-tier, 2-tier, 3-niveles, N-niveles

Arquitectura: Arte de proyectar y construir (edificios)

Architecture: the art or science of building

Page 17: Tema 1: Patrones Arquitectónicos

Arquitectura 1-tier

• Aplicaciones monolíticas• Las capas de

presentación, lógica y datos se mezclan en una mismo nivel

• Suelen ser cerrados y no presentan ningún tipo de interfaz

• Son un ejemplo claro de sistemas heredados

• ¿qué hacemos si tenemos que integrarlo?

• ¿tienen alguna ventaja?

C l i e n t e

C a p a d e P r e s e n t a c i ó n

C a p a d e L ó g i c a d e a p l i c a c i ó n

C a p a d e A c c e s o a

D a t o s / R e c u r s o s

Sis

tem

a d

e I

nfo

rma

ció

n

Page 18: Tema 1: Patrones Arquitectónicos

Arquitectura 2-tier

• Surge con la aparición de los PCs• Se vio la posibilidad de sacar la capa de

presentación a otro nivel• Ventajas:

• Se pude aprovechar las capacidad de computo del cliente

• Permite personalizar la capa de presentación para distintos fines y portarla a distintos entornos

• Un caso particular son las arquitecturas cliente/servidor

• Surgieron los RPC (Remote Procedure Call) lo que motivó para la creación de APIs

• Si el cliente es independiente del servidor, ¿qué puede suceder?

• Desventaja:• Cuando hay que hacer una integración

real de más de un dos sistemas resulta poco mantenible y escalable (¿?)

C l i e n t e

C a p a d e P r e s e n t a c i ó n

C a p a d e L ó g i c a d e a p l i c a c i ó n

C a p a d e A c c e s o a

D a t o s / R e c u r s o s

Sis

tem

a d

e I

nfo

rma

ció

n

Page 19: Tema 1: Patrones Arquitectónicos

Arquitectura 2-tier

Presentación 1

Lógica de aplicación

Gestión de Recursos

Servidor 1

Cliente

Presentación 2

Servidor 2

Lógica de aplicación

Gestión de Recursos

Lógica de la aplicación

Page 20: Tema 1: Patrones Arquitectónicos

Arquitectura 3-tier

• Debido al problema de integración de varios sistemas aparece un nuevo nivel (middleware, nivel intermedio)

• La capa presentación reside en el cliente, la capa lógica reside en el nivel intermedio, y la capa de datos reside en el nivel de recursos que está compuesto por tantos recursos como el sistema pretende integrar

• La responsabilidad de integrar pasa al middleware (CORBA, DCOM, ESB), que también se encarga de:

• Transacciones

• Balanceo de carga

• Replicación

• 3-tier separa el nivel lógico de datos (recursos) por lo que es más fácilmente escalable. Es la opción a seguir si se pretende hacer una integración de sistemas, ¿por qué?

Cliente

Presentación

Lógica de aplicación

Gestión de Recursos

SID

middleware

Page 21: Tema 1: Patrones Arquitectónicos

Arquitectura N-tier

• Es la arquitectura n-tier escalada tantas veces como sea necesario

• La capa de recursos (datos) puede ser otro sistema n-tier

Presentación

Lógica de aplicación

Gestión de Recursos

SID

middleware

1-tier 3-tier

Page 22: Tema 1: Patrones Arquitectónicos

Patrón MVCMVC: es un patrón de arquitectura de software que separa los

datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de Datos y el controlador representa la Lógica de negocio.

• Modelo: Esta es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comprar un número de unidades negativo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o importes en un carrito de la compra

• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.

• Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.

• Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona específicamente esta capa de acceso a datos.

Frameworks comunes:

Page 23: Tema 1: Patrones Arquitectónicos

Arquitecturas SOA

• SOA: Service Oriented Architecture

InterneInterne

tt HTTPHTTP

InterneInterne

tt HTTPHTTP

XMLXMLXMLXMLXML

XMLXMLXML

XMLXMLXMLXML

XMLXMLXMLXML

SOAP

SOAP

SOAP

SOAP

SOAP

SOAP

SO

AP

SO

AP

Page 24: Tema 1: Patrones Arquitectónicos

Bibliografía

• Web Services Concepts, Architectures and ApplicationsAlonso, G., Casati, F., Kuno, H., Machiraju, V. 2004, SpringerISBN: 3-540-44008-9

• Pattern-Oriented Software Architecture Buschmann, F. et. al 1996, John Wiley & Sons ISBN: 0471958697