T8 - Diseño arquitectonico - Departamento de Lenguajes y Sistemas

escuela técnica superior
de ingeniería informática
Tema 8:
Diseño arquitectónico
Ingeniería del Software
de Gestión II
Objetivos
♦  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
El Camino
♦  El diseño arquitectónico
♦  UML para diseño arquitectónico
♦  Estilo arquitectónico
♦  Patrones arquitectónicos
♦  Conclusiones
♦  Bibliografía
Arquitectura Software
♦  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, …)
Ejemplo de Arquitectura
♦  Diagrama de componentes (Proyecto Alcuza)
5
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
♦  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
Análisis y
requisitos
Infraestructura
Patrones
arquitectónicos
Documento de diseño
arquitectónico
(Arquitectura Software)
Arquitectura Software
♦  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.
Arquitecturas Software: Beneficios
♦  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)
El Camino
♦  El diseño arquitectónico
♦  UML para diseño arquitectónico
♦  Estilo arquitectónico
♦  Patrones arquitectónicos
♦  Conclusiones
♦  Bibliografía
UML para diseño arquitectónico
Modelo
estático
• Diagramas de paquetes
• Diagramas de componentes
Modelo
dinámico
• Diagramas de secuencia
• Diagramas de comunicación
• Diagramas de estado
Modelo de
distribución
• Diagramas de despliegue
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
Ejemplo de Diagrama de Componentes
♦  Diagrama de componentes (Proyecto Alcuza)
1
4
Ejemplo de Diagrama de Actividades
♦  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.
P2:T1 OK
P2:T1 OK
P2:T1 OK
1
5
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
Estilos arquitectónicos
♦  Un diseño arquitectónico se refiere
arquitectura de un sistema concreto.
a
la
♦  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
♦  …
Centrada en datos (Blackboard)
Fuente de
Conocimiento
Fuente de
conocimiento
Pizarra (datos
compartidos)
Fuente de
conocimiento
Fuente de
conocimiento
♦  El centro de la
arquitectura es una
pizarra y otros
componentes tienen
acceso a él para
actualizar, agregar,
eliminar o consultar sus
datos.
♦  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
Componente
Componente
Componente
♦  Formada por distintos
componentes
independientes que se
comunican.
♦  Los componentes pueden
estar distribuidos.
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
Capa
Capa
♦  Se definen distintas capas en la
aplicación de manera que sólo se
comunican entre si las capas
adyacentes.
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
Es la interfaz de usuario. Hace la información
accesible al usuario
Capa de lógica de aplicación
Coordina la aplicación, procesa los comandos,
toma decisiones, realiza los cálculos y mueve
los datos entre las dos capas.
Capa de datos / recursos
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
Lógica de
aplicación
Gestión de
Recursos
Sistema de Información
Presentació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
SI
Presentación
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
Presentación
Lógica de
aplicación
Gestión de
Recursos
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
Capa de gestión de recursos
Presentación
Lógica de
aplicación
Gestión de
Recursos
Responsable de: gestionar todos los elementos
de información del SI; ficheros planos, XML,
SGBD,
También conocida como capa de acceso a datos
¿Qué otros elementos pueden proporcionar
información?
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
El Camino
♦  El diseño arquitectónico
♦  UML para diseño arquitectónico
♦  Estilo arquitectónico
♦  Patrones arquitectónicos
♦  Conclusiones
♦  Bibliografía
Patrones arquitectónicos
♦  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
Arquitecturas x-tier
•  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.
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
Arquitectura en dos niveles
Cliente
Presentación
Lógica de
aplicación
Servidor
Gestión de
Recursos
SI
•  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’
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
Cliente
Lógica de la aplicación
Presentación 1
Presentación 2
Servidor 2
Servidor 1
Lógica de
aplicación
Lógica de
aplicación
Gestión de
Recursos
Gestión de
Recursos
Arquitectura en tres niveles
• 
• 
• 
• 
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
middleware
SID
•  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):
Gestión de
Gestión
de recursos
Recursos
Arquitecturas multinivel
Cliente
Navegador
Presentación
Filtro HTML
Lógica de
aplicación
Servidor WEB
middleware
SID
•  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
Gestión de
Gestión de recursos
Recursos
Arquitecturas multinivel
remote
clients
...
INTERNET
internal
clients
Web
server
cluster
LAN
LAN
middleware
application
logic
LAN,
gateways
LAN
middleware
application
resource
management
layer
logic
LAN
database
server
file
server
application
additional resource
management layers
Wrappers
and
gateways
LAN
Copyright Springer Verlag Berlin Heidelberg 2004
FIREWALL
Patrones arquitectónicos
♦  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
Capa de presentación
MVC
Capa de lógica de aplicación
Capa de datos / recursos
Interacción con el usuario
♦  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)
Modelo
consulta
Envía datos
actualiza
Eventos del usuario
Vista
modifica
Controlador
Interacción con el usuario
Interacción con el usuario
♦  Front Controller
♦  Page Controller
Patrones arquitectónicos
♦  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
Capa de presentación
Capa de lógica de aplicación
DAO
y/o
ORM
Capa de datos / recursos
Interacción con la capa de datos
♦  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
Business Objetcs
- clases
- asociaciones
- agregaciones
- composiciones
- herencia
mapping
♦  Hibernate
♦  iBatis
♦  Toplink
♦  JPA
Relational Data
Base
- sql
- transaciones
- cacheo
-…
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
♦  Es difícil encontrar el
framework apropiado
♦  Experiencia del diseñador ♦  Es difícil usar más de un
framework al mismo
del framework
tiempo
♦  Costes de producción
♦  Son difíciles de construir y
reducidos
de aprender a usar
Patrones y frameworks
♦  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.
El Camino
♦  Introducción
♦  El diseño arquitectónico
♦  UML para diseño arquitectónico
♦  Estilo arquitectónico
♦  Patrones arquitectónicos
♦  Conclusiones
♦  Bibliografía
Conclusiones
♦  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
El Camino
♦  El diseño arquitectónico
♦  UML para diseño arquitectónico
♦  Estilo arquitectónico
♦  Patrones arquitectónicos
♦  Conclusiones
♦  Bibliografía
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