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?
Arquitectura Software
♦ 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.
Arquitectura Software
♦ 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
♦ El diseño arquitectónico ♦ UML para diseño arquitectónico ♦ Estilo arquitectónico
♦ Patrones arquitectónicos ♦ Conclusiones ♦ Bibliografía
• 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…
Diagramas de despliegue
♦ Despliegue de dos ficheros JAR en un servidor de aplicaciones:
Diagramas de despliegue
♦ 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.
Diagramas de despliegue
♦ Despliegue de elementos en una red
El Camino
♦ El diseño arquitectónico ♦ UML para diseño arquitectónico ♦ Estilo arquitectónico
♦ Patrones arquitectónicos ♦ Conclusiones ♦ Bibliografía
♦ 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
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)
Capa de presentación
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
Capa de lógica de aplicación
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
Lógica de aplicació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
Lógica de aplicación
Gestión de Recursos ¿Qué otros elementos pueden proporcionar
información?
También conocida como capa de acceso a datos
El Camino
♦ El diseño arquitectónico ♦ UML para diseño arquitectónico ♦ Estilo arquitectónico
♦ Patrones arquitectónicos ♦ Conclusiones ♦ Bibliografía
♦ 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
Patrones arquitectónicos
• 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
Lógica de aplicación
Gestión de Recursos
SI
Arquitectura en dos niveles
• 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
Arquitectura en dos niveles
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
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
Lógica de aplicación
Gestión de Recursos
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
Lógica de aplicación
Gestión de Recursos
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
Patrones arquitectónicos
Interacción con el usuario
Capa de presentación
Capa de lógica de aplicación
Capa de datos / recursos
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.
Interacción con el usuario
♦ MVC (Modelo – Vista – Controlador)
Interacción con el usuario
Modelo
Vista Controlador
Eventos del usuario
modifica
actualiza Envía datos consulta
Interacción con el usuario
♦ Front Controller
♦ Page Controller
Interacción con el usuario
♦ Interacción entre componentes ♦ Cliente / servidor
♦ Arquitecturas x-tier
♦ Interacción con el usuario ♦ MVC
♦ Interacción con la capa de datos ♦ ORM
♦ DAO
Patrones arquitectónicos
Interacción con la capa de datos
Capa de presentación
Capa de lógica de aplicación
Capa de datos / recursos
DAOy/o ORM
♦ Patrón Data Access Object
♦ Se suele combinar con patrones factory para la creación de objetos DAO
Interacción con la capa de datos
♦ Uso de DAO
Interacción con la capa de datos
♦ Object Relational Mapping
Interacción con la capa de datos
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
♦ El diseño arquitectónico ♦ UML para diseño arquitectónico ♦ Estilo arquitectónico
♦ Patrones arquitectónicos ♦ Conclusiones ♦ Bibliografía
♦ 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
Top Related