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 • Diagramas de paquetes

estático • Diagramas de componentes

• Diagramas de secuencia
Modelo • Diagramas de comunicación
dinámico • Diagramas de estado

Modelo de • Diagramas de despliegue

distribución
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 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
♦  …
 Centrada en datos (Blackboard)
♦  El centro de la
Fuente de
Conocimiento

arquitectura es una
Fuente de pizarra y otros
conocimiento
Pizarra (datos Fuente de componentes tienen
compartidos) conocimiento
acceso a él para
actualizar, agregar,
Fuente de
conocimiento
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
♦  Formada por distintos
componentes
independientes que se
Componente
Componente 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 ♦  Se definen distintas capas en la
aplicación de manera que sólo se
Capa 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

Es la interfaz de usuario. Hace la información

Capa de presentación accesible al usuario

Coordina la aplicación, procesa los comandos,

Capa de lógica de aplicación toma decisiones, realiza los cálculos y mueve
los datos entre las dos capas.

Es de donde se obtiene la información y los

Capa de datos / recursos datos. Suele ser una base de datos, ficheros
externos, recursos accesibles por la web…
3C en aplicaciones de gestión

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

Sistema de Información
Lógica de También conocida como vista
aplicación lógica de la arquitectura.

Gestión de Capa (Layer), Nivel (Tier)

Recursos
 Capa de presentación

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

SI
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

Presentación
solicitadas por los clientes a la capa de
presentación.
Lógica de
aplicación Ej: el componente responsable de ‘traspasar’
dinero de una cuenta es un componente
Gestión de habitual
Recursos

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

Responsable de: gestionar todos los elementos

Presentación
de información del SI; ficheros planos, XML,
SGBD,
Lógica de
aplicación También conocida como capa de acceso a datos

Gestión de
Recursos ¿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

•  La popularización del PC hizo rentable

pasar la responabilidad de la capa de
presentación al cliente Cliente
•  Se conoce como Cliente/Servidor
•  Dependiendo de las responsabilidades del
cliente se habla de clientes ‘pesados’ o Presentación
‘ligeros’.
•  Clientes ligeros
•  + fáciles de mantener, instalar y portar Lógica de

SI
•  Requieren menos recursos aplicación

•  Se confunde cliente con capa de Servidor

presentación
Gestión de
•  Popularizó las ‘remote procedure Recursos
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 1 Servidor 2

Lógica de Lógica de
aplicación aplicación

Gestión de Gestión de
Recursos Recursos
 Arquitectura en tres niveles

•  Algunos la justifican como la

evolución natural de las dos capas
para resolver el problema de la Cliente
integración de varios servidores
•  La responsabilidad de integrar pasa al
middleware, que también se encarga Presentación
de (CORBA, X/OPEN, DCOM):
•  Transacciones
•  Balanceo de carga Lógica de
aplicación

•  Replicación
•  …. middleware

•  Permiten desplegar lógica en otro host

SID
•  La latencia aumenta ¿compensa?
Gestión de
•  Popularizó ODBC (interfaz pública y Gestión de recursos
Recursos

estable)
Arquitecturas multinivel
•  Es la arquitectura en n-niveles Cliente
escalada tantas veces como
sea necesario Navegador

•  La capa de recursos (datos)

puede tener a su vez otra Presentación
arquitectura n-nivel
•  Surge de manera natural
Filtro HTML Servidor WEB

cuando i) se desea integrar

varios sistemas de
información y/o ii) se desea
utilizar Internet como canal de Lógica de
aplicación
comunicación
middleware

SID
Gestión de
Gestión de recursos
Recursos
Arquitecturas multinivel
remote
clients ...

INTERNET

FIREWALL

internal

Copyright Springer Verlag Berlin Heidelberg 2004

clients Web
server
LAN cluster

LAN
middleware
application
LAN,
logic gateways

LAN

middleware Wrappers
resource application and
management logic gateways
layer LAN LAN

database file application additional resource

server server management layers
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 Relational Data
- clases Base
- asociaciones mapping - sql
- agregaciones - transaciones
- composiciones - cacheo
- herencia -…

♦  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 ♦  Es difícil encontrar el

código framework apropiado
♦  Experiencia del diseñador ♦  Es difícil usar más de un
del framework framework al mismo
tiempo
♦  Costes de producción
reducidos ♦  Son difíciles de construir y
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