tema 8: diseño arquitectónico

escuela técnica superior de ingeniería informática

Ingeniería del Software

de Gestión II

Tema 8: Diseño arquitectónico

♦  Comprender el diseño arquitectónico (DA)

♦  Conocer diagramas comúnmente usados en DA

♦  Conocer estilos y patrones arquitectónicos habituales en aplicaciones de gestión

♦  Conocer el concepto de framework

Objetivos

El Camino

♦ El diseño arquitectónico ♦ UML para diseño arquitectónico ♦ Estilo arquitectónico

♦ Patrones arquitectónicos ♦ Conclusiones ♦ Bibliografía

♦  Programas= Algoritmos + Estructura de Datos

♦  ¿y la estructura del programa?

♦  Aumento en complejidad de un sistema software mayor importancia al diseño y especificación de la estructura global del sistema que a la elección de algoritmos y estructuras de datos (microarquitectura)

♦  Definición de arquitectura de un sistema software según Bass et al (1998):

“Estructura o estructuras del sistema, incluyendo: sus componentes software, las propiedades observables de dichos componentes y las relaciones entre ellos.”

♦  Es el primer documento en el que se establece una prioridad entre propiedades de calidad al tiempo que se recogen todos los requisitos y restricciones (funcionales, infraestructura, …)

Arquitectura Software

♦  Diagrama de componentes (Proyecto Alcuza)

5

Ejemplo de Arquitectura

♦  Diseño Arquitectónico: Concepción original (proceso) de la Arquitectura Software de un sistema a fin de construirlo con la máxima calidad y dentro de un plazo y tiempo determinados.

♦  Se recomienda comenzar en un alto grado de abstracción y refinar sucesivamente hasta llegar al nivel de componente

♦  Se recomienda seguir ‘buenas prácticas’

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

Documento de diseño arquitectónico

(Arquitectura Software)

Patrones arquitectónicos

Infraestructura

Análisis y requisitos

Diseño Arquitectónico

♦  Aspectos que abarca el diseño de una AS (Shaw and Garlan, 96): ♦  the organization of a system as a composition of components;

♦  global control structures;

♦  the protocols for communication, synchronization and data access;

♦  the assignement of functionality to design elements;

♦  the composition of design elements;

♦  physical distribution;

♦  scaling and performance;

♦  dimensions of evolution;

♦  selection among design alternatives

♦  ¿Cuántos aspectos sabrías describir?


♦  Aspectos con técnicas comúnmente aceptadas: ♦  the organization of a system as a composition of components:

Diagrama de componentes (DC) de UML

♦  physical distribution: Diagrama de despliegue (DD) de UML

♦  global control structures: DC

♦  the protocols for communication, synchronization and data access; DD, extensiones UML, lenguajes formales (Wright, LEDA, …)

♦  the assignement of functionality to design elements: DC, DD

♦  the composition of design elements; DC, DD

♦  scaling and performance: Técnicas textuales

♦  dimensions of evolution: Técnicas textuales

♦  selection among design alternatives: Técnicas textuales

♦  Existen lenguajes específicos de descripción de arquitecturas, pero nosotros usaremos UML.


♦  Describir explícitamente la arquitectura de un sistema software proporciona beneficios: ♦  Durante la gestión del sistema

♦ Documento sobre el que poder discutir

♦ Aumenta la precisión en la estimación del coste y tiempo

♦ El arquitecto proporciona información útil

♦  Durante el desarrollo del sistema ♦ Es una excelente vista general y consistente de múltiples

vistas del sistema

♦ Proporciona la relación de puntos de diseño a tratar

♦ Facilita el desarrollo simultáneo de componentes

♦ Facilita la reutilización a gran escala ( es la base para construir líneas de productos)

Arquitecturas Software: Beneficios

El Camino



• Diagramas de paquetes • Diagramas de componentes

Modelo estático

• Diagramas de secuencia • Diagramas de comunicación • Diagramas de estado

Modelo dinámico

• Diagramas de despliegue Modelo de distribución

UML para diseño arquitectónico

Diagramas de componentes

♦  Los diagramas de componente muestran los bloques de software que componen un sistema.

♦  Un componente se implementa con una o más clases.

♦  Un componente puede tener interfaces de salida e interfaces de entrada

♦  Diagrama de componentes (Proyecto Alcuza)

14

Ejemplo de Diagrama de Componentes

♦  Arquitectura Alcuza: dirigida por eventos

♦  EDA para maximizar desacoplamiento

♦  Ejemplo: el gestor de tareas no sabe de la existencia de un motor de tareas, solo sabe que debe publicar los eventos de terminación de tarea.

15

Ejemplo de Diagrama de Actividades

P2:T1 OK

P2 :T

1 OK

P2:T1 OK

Diagramas de despliegue

♦ Muestra la estructura en tiempo de ejecución del sistema, esto es, la configuración del hardware y cómo el software se distribuye en él

♦  Dos conceptos:

Nodo • Elemento hardware • Entorno de ejecución • El tipo se especifica con

estereotipos

Artefacto • Cualquier producto del

proceso de desarrollo • Ejecutables, código fuente,

modelos, documentación…


♦  Despliegue de dos ficheros JAR en un servidor de aplicaciones:


♦  Despliegue de varios ficheros JAR en un entorno de ejecución J2EEServer que está en un servidor de aplicaciones y que se conecta con un servidor de base de datos.


♦  Despliegue de elementos en una red

El Camino



♦  Un diseño arquitectónico se refiere a la arquitectura de un sistema concreto.

♦  Un estilo arquitectónico define componentes, relaciones entre componentes y restricciones sobre esas relaciones, esto es, establece las restricciones sobre la arquitectura de una familia de diseños arquitectónicos.

♦ Centrada en datos

♦ Flujo de datos

♦ Por capas

♦ Componentes independientes

♦ …

Estilos arquitectónicos

Centrada en datos (Blackboard) ♦  El centro de la

arquitectura es una pizarra y otros componentes tienen acceso a él para actualizar, agregar, eliminar o consultar sus datos.

Pizarra (datos compartidos)

Fuente de conocimiento



Fuente de Conocimiento

♦  Facilita la integración pues los componentes son independientes.

♦  Se puede pasar datos entre componentes a través del almacén de datos.

♦  Ejercicio: Identifica el estilo: componentes, relaciones, restricciones, …

♦  ¿se pueden comunicar directamente dos componentes?

Tuberias y Filtros

Filtro Filtro

Filtro

Filtro

Filtro

Filtro

♦  Se aplica cuando los datos de entrada se han de transformar en datos de salida mediante una serie de operaciones.

♦  Los componentes (filtros) van transmitiendo datos al siguiente por medio de tuberías.

♦  Los filtros no necesitan saber el funcionamiento de los vecinos. Sólo se preocupan de su entrada y su salida.

♦  Si hay una sola línea de transformaciones se denomina procesamiento por lotes secuencial (pipeline).

Componentes independientes

♦  Formada por distintos componentes independientes que se comunican.

♦  Los componentes pueden estar distribuidos.

Componente

Componente

Componente

Componente

♦  Un subestilo es que los componentes sigan una jerarquía de control donde un programa principal invoca a varios componentes de programa que pueden invocar a otros componentes.

Múltiples Capas ♦  Se definen distintas capas en la

aplicación de manera que sólo se comunican entre si las capas adyacentes.

Capa

Capa

Capa

♦  Los estilos se suelen mezclar. Por ejemplo, una arquitectura por capas puede usar un estilo diferente en cada capa: ♦ Que las dos últimas capas sean una arquitectura

centrada en datos.

♦  Una capa se implemente como un flujo de datos o con componentes independientes.

Estilo habitual de las aplicaciones de gestión

Capa de presentación

Capa de lógica de aplicación

Capa de datos / recursos

Es la interfaz de usuario. Hace la información accesible al usuario

Coordina la aplicación, procesa los comandos, toma decisiones, realiza los cálculos y mueve los datos entre las dos capas.

Es de donde se obtiene la información y los datos. Suele ser una base de datos, ficheros externos, recursos accesibles por la web…

3C en aplicaciones de gestión

Cliente

Presentación

Lógica de aplicación

Gestión de Recursos S

iste

ma

de In

form

ació

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)


Cliente

Presentación

SI

Responsable de: (1) presentar información e (2) interactuar con entidades externas

Diferentes apariencias: GUI, módulo de transformación de ficheros, ….

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

¿Cuál es el cliente y cuál la capa de presentación de una aplicación que ofrece una página HTML con applets? ¿Y si no tuviera applets?

Todos los Sistemas de Información (SI) tienen un CLIENTE, pero no todos los clientes pertenecen al SI, pueden ser externos


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

Ej: el componente responsable de ‘traspasar’ dinero de una cuenta es un componente habitual

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 de negocio o simplemente servidor

Presentación


Gestión de Recursos

Capa de gestión de recursos

Responsable de: gestionar todos los elementos de información del SI; ficheros planos, XML, SGBD,

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 SSII a partir de otros SSII

denominar a esta capa como ‘capa de datos’ es ignorar prácticas muy habituales

Presentación


Gestión de Recursos ¿Qué otros elementos pueden proporcionar

información?

También conocida como capa de acceso a datos

El Camino



♦  Abarcan aspectos específicos del comportamiento dentro de la arquitectura

♦  Tienen un alcance menor que los estilos arquitectónicos (se concentran en un solo aspecto)

♦  Interacción entre componentes ♦  Arquitecturas x-tier

♦  Interacción con el usuario ♦  MVC

♦  Interacción con la capa de datos ♦  ORM

♦  DAO


•  Durante el Diseño Arquitectónico la vista lógica de una arquitectura en capas (layer) conceptuales da lugar a una vista física que se materializa en una arquitectura en uno o más niveles (tier)

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

♦  En inglés existe la diferencia entre layer (las capas de antes) y tier (nivel). Sin embargo, en español, se suelen traducir ambas como capa, lo que da lugar a confusión.

Arquitecturas x-tier

Arquitectura mononivel

•  Por razones de rendimiento el resultado de implementar las tres capas se queda en un único aplicativo. Se despliega en un único host.

•  No ofrecen acceso programático (API).

•  Es el ejemplo canónico de sistema legado. Se suele utilizar ‘screen scraping’ para su integración

•  Ventajas

•  Eficiencia

•  Coste casi nulo de despliegue y desarrollo en clientes.

•  Inconvenientes

•  Coste (€, t) de mantenimiento de la aplicación

•  Mainframes es una tendencia opuesta a la de clusters

Servidor

Arquitectura en dos niveles

•  La popularización del PC hizo rentable pasar la responabilidad de la capa de presentación al cliente

•  Se conoce como Cliente/Servidor •  Dependiendo de las responsabilidades del

cliente se habla de clientes ‘pesados’ o ‘ligeros’.

•  Clientes ligeros •  + fáciles de mantener, instalar y portar •  Requieren menos recursos •  Se confunde cliente con capa de

presentación •  Popularizó las ‘remote procedure

calls’ (RPC). Para conseguir buen acoplamiento se comenzó a utilizar interfaces ‘públicas’ y ‘estables’

Cliente

Presentación



SI


•  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 (multiplataforma)

•  Eficiencia en el lado del servidor

•  Inconvenientes •  Protocolos más complejos y gestión de sesiones

complican la escalabilidad

•  Arquitectura inadecuada cuando se necesita integrar más de un servidor


Presentación 1



Servidor 1

Cliente

Presentación 2

Servidor 2



Lógica de la aplicación

Arquitectura en tres niveles

•  Algunos la justifican como la evolución natural de las dos capas para resolver el problema de la integración de varios servidores

•  La responsabilidad de integrar pasa al middleware, que también se encarga de (CORBA, X/OPEN, DCOM): •  Transacciones •  Balanceo de carga •  Replicación •  ….

•  Permiten desplegar lógica en otro host •  La latencia aumenta ¿compensa? •  Popularizó ODBC (interfaz pública y

estable)

Cliente

Presentación



SID

middleware

Gestión de recursos

Arquitecturas multinivel

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

•  La capa de recursos (datos) puede tener a su vez otra arquitectura n-nivel

•  Surge de manera natural cuando i) se desea integrar varios sistemas de información y/o ii) se desea utilizar Internet como canal de comunicación

Filtro HTML



SID

middleware

Gestión de recursos

Servidor WEB

Navegador

Presentación

Cliente

Arquitecturas multinivel

resource management layer

. . . remote clients

INTERNET

FIREWALL

LAN

Web server cluster

LAN, gateways

LAN

internal clients

LAN

middleware application logic

database server

LAN

middleware application logic

additional resource management layers

LAN

Wrappers and gateways

file server

application

Cop

yrig

ht S

prin

ger V

erla

g B

erlin

Hei

delb

erg

2004

♦  Interacción entre componentes ♦  Arquitecturas x-tier

♦  Interacción con el usuario ♦ MVC

♦  Interacción con la capa de datos ♦ ORM

♦  DAO


Interacción con el usuario




MVC

♦ MVC (Modelo – Vista – Controlador) ♦ Modelo es la representación específica de la

información con la que se opera. Incluye los datos y la lógica para operar con ellos.

♦  Vista es la presentación del modelo de forma adecuada para interactuar con ella, normalmente a través de una interfaz de usuario.

♦  Controlador responde a eventos de la interfaz de usuario e invoca cambios en el modelo y probablemente en la vista.


♦ MVC (Modelo – Vista – Controlador)


Modelo

Vista Controlador

Eventos del usuario

modifica

actualiza Envía datos consulta

♦  Front Controller

♦  Page Controller


♦  Interacción entre componentes ♦  Cliente / servidor

♦  Arquitecturas x-tier

♦  Interacción con el usuario ♦ MVC

♦  Interacción con la capa de datos ♦ ORM

♦  DAO


Interacción con la capa de datos




DAOy/o ORM

♦  Patrón Data Access Object

♦  Se suele combinar con patrones factory para la creación de objetos DAO


♦  Uso de DAO


♦ Object Relational Mapping


Business Objetcs - clases - asociaciones - agregaciones - composiciones - herencia

Relational Data Base - sql - transaciones - cacheo - …

mapping

♦  Hibernate

♦  iBatis

♦  Toplink ♦  JPA

Frameworks

♦  Conjunto de clases parcialmente funcional (no es una aplicación) para un dominio de aplicación

♦  Les falta aquello que es propio de la aplicación

♦  Ejemplos: AWT, Swing, Struts, Junit, Compact Framework, James (genuinamente andaluz), …

♦  Gran influencia en el diseño de la aplicación cliente

El principio de Hollywood

El principio de Hollywood

Main() { i1 = new I1(); i2 = new I2(); i1 = i2.m(i1.g()); }

Ventajas e inconvenientes

♦  Reutilización de diseño y código

♦  Experiencia del diseñador del framework

♦  Costes de producción reducidos

♦  Es difícil encontrar el framework apropiado

♦  Es difícil usar más de un framework al mismo tiempo

♦  Son difíciles de construir y de aprender a usar

♦  Los frameworks nos implementan en ocasiones distintos patrones y estilos arquitectónicos.

♦  Por ejemplo, Struts, JSF `y ASP .net implementan el patrón MVC.

♦  J2EE nos da soporte para un estilo arquitectónico con tres capas (presentación, lógica de aplicación y datos)

♦  Por tanto, el uso de frameworks va a determinar en gran medida la arquitectura del sistema.

Patrones y frameworks

El Camino

♦  Introducción ♦ El diseño arquitectónico ♦ UML para diseño arquitectónico

♦ Estilo arquitectónico ♦ Patrones arquitectónicos ♦ Conclusiones ♦ Bibliografía

♦  El diseño arquitectónico es fundamental para el resultado final del desarrollo software.

♦  Podemos tener modelos estáticos (paquetes, componentes), dinámicos (secuencia, comunicación, estados) y de despliegue.

♦  Los estilos arquitectónicos definen la estructura general del sistema.

♦  Los patrones arquitectónicos resuelven aspectos específicos dentro de la arquitectura.

Conclusiones

♦  Para aplicaciones de gestión lo más habitual actualmente es: ♦  Aplicaciones en tres capas: presentación, lógica de

negocio y datos.

♦  Arquitecturas N-tier.

♦  Uso del patrón arquitectónico MVC para la interfaz de usuario.

♦  Uso de ORM

Conclusiones

El Camino



♦  Básica (de referencia):

♦  “Ingeniería del Software. Un enfoque práctico”. Roger S. Pressman. Mc Graw Hill (6ª ed.)

♦  De apoyo:

♦  “Ingeniería del Software”. Ian Sommerville. Pearson Addison Wesley (7ª ed.)

♦  Sobre UML: ♦  http://sparxsystems.com.au/resources/uml2_tutorial/

♦  MVC: ♦  http://java.sun.com/blueprints/patterns/MVC-detailed.html

♦  http://java.sun.com/blueprints/patterns/FrontController.html

♦  http://msdn.microsoft.com/en-us/library/ms978764.aspx

♦  DAO: ♦  http://java.sun.com/blueprints/corej2eepatterns/Patterns/

DataAccessObject.html

Bibliografía

tema 8: diseño arquitectónico

Documents