Tema 8: Diseño arquitectónico Ingeniería del Software de Gestión II

Transcripción

1 escuela técnica superior de ingeniería informática Tema 8: Diseño arquitectónico Ingeniería del Software de Gestión II

2 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

3 El Camino El diseño arquitectónico UML para diseño arquitectónico Estilo arquitectónico Patrones arquitectónicos Conclusiones Bibliografía

4 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, )

5 Ejemplo de Arquitectura Diagrama de componentes (Proyecto Alcuza) 5

6 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

7 Diseño Arquitectónico Infraestructura Análisis y requisitos Patrones arquitectónicos Documento de diseño arquitectónico (Arquitectura Software)

8 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?

9 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.

10 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)

12 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

13 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

14 Ejemplo de Diagrama de Componentes Diagrama de componentes (Proyecto Alcuza) 1 4

15 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. P 2 :T 1 OK P2 :T 1 OK P 2 :T 1 OK 1 5

16 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

17 Diagramas de despliegue Despliegue de dos ficheros JAR en un servidor de aplicaciones:

18 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.

19 Diagramas de despliegue Despliegue de elementos en una red

21 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

22 Centrada en datos (Blackboard) Fuente de conocimiento Pizarra (datos compartidos) Fuente de conocimiento 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?

23 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).

24 Componentes independientes Componente Componente Componente Componente Formada por distintos componentes independientes que se comunican. Los componentes pueden estar distribuidos. 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.

25 Múltiples Capas Capa Capa Capa Se definen distintas capas en la aplicación de manera que sólo se comunican entre si las capas adyacentes. 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.

26 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

27 3C en aplicaciones de gestión Cliente Presentación Lógica de aplicación Gestión de Recursos Sistema de Informació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)

28 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

29 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

30 Capa de gestión de recursos Presentación Lógica de aplicación Responsable de: gestionar todos los elementos de información del SI; ficheros planos, XML, SGBD, 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

32 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

33 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.

34 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

35 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 Servidor Gestión de Recursos SI

36 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

37 Arquitectura en dos niveles Cliente Lógica de la aplicación Presentación 1 Presentación 2 Servidor 1 Servidor 2 Lógica de aplicación Lógica de aplicación Gestión de Recursos Gestión de Recursos

38 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 middleware Gestión de Gestión Recursos de recursos SID

39 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 Cliente Navegador Presentación Servidor WEB middleware SID Gestión de Recursos Gestión de recursos

40 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

41 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

42 Interacción con el usuario Capa de presentación MVC Capa de lógica de aplicación Capa de datos / recursos

43 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.

44 Interacción con el usuario MVC (Modelo Vista Controlador) Modelo consulta Envía datos actualiza Vista Eventos del usuario modifica Controlador

45 Interacción con el usuario

46 Interacción con el usuario Front Controller Page Controller

47 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

48 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

49 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

50 Interacción con la capa de datos Uso de DAO

51 Interacción con la capa de datos Object Relational Mapping Business Objetcs - clases - asociaciones - agregaciones - composiciones - herencia mapping Relational Data Base - sql - transaciones - cacheo - Hibernate ibatis Toplink JPA

52 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

53 El principio de Hollywood

54 El principio de Hollywood Main() { i1 = new I1(); i2 = new I2(); i1 = i2.m(i1.g()); }

55 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

56 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.

57 El Camino Introducción El diseño arquitectónico UML para diseño arquitectónico Estilo arquitectónico Patrones arquitectónicos Conclusiones Bibliografía

58 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.

59 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

61 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: MVC: DAO: DataAccessObject.html