Ingeniería de Software II - Universidad de Buenos Aires
Anuncio
Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 4: Introducción a las arquitecturas de software. Estilos arquitectónicos Buenos Aires, 3 de Abril de 2008 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Analizando dibujitos… 2 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Banco © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Google © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Marcapasos © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Mozilla © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Interfaz © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Reconocimiento de Voz © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Algunas analogías Fuente: Virginia McAlester. A Field Guide to American Houses. 9 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Algunas analogías (cont.) 10 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Algunas analogías (cont.) 11 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 De los requerimientos a la implementación Requerimientos Y ahora? Un milagro ocurre Cómo construimos un puente entre los requerimientos y la implementación? Implementación 12 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitecturas de sistemas de software La arquitectura de un sistema de software: Define el sistema en términos de componentes e interacción entre ellos Muestra correspondencia entre requerimientos y elementos del sistema construido Resuelve atributos de calidad en el nivel del sistema, como escalabilidad, compatibilidad, confiabilidad y performance. Muchos piensan (pensamos) que los avances en el tema de arquitecturas de software son un paso clave para poder lograr el reuso a gran escala y ayudar a que la ingeniería de software empiece a asemejarse a otras disciplinas de la ingeniería. 13 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Analogías con la ingeniería civil (sólo edificios) Estilos arquitectónicos: colonial, victoriano, griego Paradigmas de organización de sistemas de software: pipes, layers, events Conocimientos específicos para un estilo en particular: cárceles, fábricas automotrices, hospitales, hoteles 5 estrellas. Arquitecturas para un dominio específico 14 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Por qué este tema es importante? El mantenimiento de grandes sistemas suele llevar más del 60% del esfuerzo total Un 50% del esfuerzo de los programadores de mantenimiento se va en analizar y entender el código y la documentación existente. La arquitectura hace una diferencia. La arquitectura posibilita o inhibe alcanzar los requerimientos de calidad de un sistema. 15 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 La estructura de los sistemas La arquitectura trata sobre la estructura de los sistemas Cómo el sistema se descompone en partes Cómo esas partes interactúan Pero esto lleva a la pregunta: ¿Qué tipos de estructuras? Del código Run-time Del entorno de desarrollo Work breakdown structures Cada una de estas estructuras puede ser la base para una vista arquitectónica (architectural view) Históricamente el foco estuvo en vistas de código 16 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Las definiciones más aceptadas (Bass, Clements) Arquitectura La arquitectura de software de un programa o sistema de computación es la estructura o estructuras del sistema, que abarcan elementos de software, las propiedades externamente visibles de estos elementos y las relaciones entre ellos. Implicancias: La arquitectura define elementos de software (privado <> arquitectónico) Los sistemas pueden tener más de una estructura Todo sistema de computación con software tiene una arquitectura El comportamiento de cada elemento es parte de la arquitectura Estilo o patrón arquitectónico Una descripción de tipos de relaciones y elementos, junto con restricciones sobre cómo deben usarse (ej. “client server”). Arquitectura de referencia Una división común de funcionalidad mapeada a elementos que cooperativamente implementan esa funcionalidad y flujos de datos entre ellos. 17 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitectura de software ¿Qué es un elemento? ¿Qué es el comportamiento? ¿Qué son la relaciones? ¿Qué es un sistema? © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitectura de software Metáfora Sistema: una ciudad Elementos: edificios, plazas, escuelas, iglesias, edificios públicos, etc. Relaciones: sus calles, red cloacal, red de gas, red de agua, puentes, etc. Comportamiento: El transito según el horario; el consumo de luz, agua, gas, etc. © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitectura de software En una Arquitectura de Software Sistema: una aplicación Elementos: sus componentes, archivos de configuración, etc. Relaciones: componentes relaciones de uso y dependencia entre Comportamiento: ¿Qué elementos entran en acción en la ejecución de una determinada funcionalidad? © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Implicancias Definición “Una arquitectura de software para un sistema es la estructura o estructuras del sistema, la cual abarca sus elementos, su comportamiento visible y las relaciones entre ellos” Implicancia La arquitectura define elementos de software (privado <> arquitectónico) © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Implicancias Definición “Una arquitectura de software para un sistema es la estructura o estructuras del sistema, la cual abarca sus elementos, su comportamiento visible y las relaciones entre ellos” Implicancia Los sistemas pueden tener más de una estructura © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Implicancias Definición “Una arquitectura de software para un sistema es la estructura o estructuras del sistema, la cual abarca sus elementos, su comportamiento visible y las relaciones entre ellos” Implicancia Todo sistema de computación con software tiene una arquitectura © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Implicancias Definición “Una arquitectura de software para un sistema es la estructura o estructuras del sistema, la cual abarca sus elementos, su comportamiento visible y las relaciones entre ellos” Implicancia El comportamiento de cada elemento es parte de la arquitectura © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Por qué es importante una arquitectura? Comunicación entre “stakeholders” Decisiones tempranas de diseño Define restricciones de implementación Afecta la estructura organizativa Posibilita o inhibe atributos de calidad de un sistema Facilita el razonamiento sobre cambios y su implementación Permite estimaciones más precisas Abstracción transferible de un sistema Los sistemas pueden ser construidos a partir de elementos externos Menos es más: es bueno restringir Permite el “desarrollo basado en templates” 25 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Algunas realidades sobre las arquitecturas Las arquitecturas son influenciadas por los “stakeholders” del sistema Las arquitecturas son influenciadas por la organización de desarrollo Las arquitecturas son influenciadas por la experiencia y el “background” de los arquitectos Las arquitecturas son influenciadas por el entorno técnico Las arquitecturas afectan los factores que las influencian 26 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Qué hace que una arquitectura sea “buena”? Producto de un único arquitecto o un pequeño grupo de arquitectos con un claro líder (Brooks, Mills y otros) El equipo de arquitectura debe contar con requerimientos funcionales y atributos de calidad requeridos que sean claros La arquitectura debe estar documentada La arquitectura debe ser revisada por los “stakeholders” Debe ser evaluada cuantitativamente antes de que sea tarde Debe permitir una implementación incremental Módulos bien definidos basados en el ocultamiento de la información Interfaz claramente definida No dependiente de un único producto comercial Usa un grupo pequeño y claro de patrones de interacción 27 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Taxonomía de estilos arquitectónicos Data Flow Batch Sequential Pipes & filters Independent components Call and return Main program / subroutines Information hiding ADT, objects Layered Client Server Event systems – implicit invocation Communicating Processes Data – Centered Repository Blackboard State Transition 28 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Propiedades de los estilos arquitectónicos Un vocabulario para los elementos de diseño Tipos de componentes y conectores Por ejemplo: clases, invocaciones, “pipes”, clientes Reglas de composición Un estilo tiene restricciones topológicas que determinan cómo se puede hacer la composición de los elementos Por ejemplo: los elementos de un “layer” se pueden comunicar sólo con los del “layer” inferior Semántica para esos elementos Idealmente, criterios para la evaluación de una arquitectura o formas de analizarla; generación de código Importante: un estilo arquitectónico no define la funcionalidad de un sistema. Desde ese punto de vista es algo “abstracto”. 29 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Beneficios de los estilos arquitectónicos Reuso de diseños Soluciones maduras aplicadas a problemas nuevos Reuso de código Una parte importante del código que implementa la arquitectura puede pasarse de un sistema a otro Comunicación Portabilidad 30 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitecturas Heterogéneas Resultan de la combinación de distintos estilos Por ejemplo: Los componentes de un sistema “layered” pueden tener una estructura interna que use otro estilo Una arquitectura hecha con J2EE probablemente resulte en una arquitectura heterogénea que incluya: Layered Repository Independent components Information hiding Objects En sistemas medianos / grandes, es más probable que un estilo arquitectónico describa una parte de un sistema que al sistema completo. 31 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitecturas tipo “Data – Flow” La estructura del sistema está basada en transformaciones sucesivas a datos de input. Los datos entran al sistema y fluyen a través de los componentes hasta su destino final. Los componentes son de run-time Normalmente un programa controla la ejecución de los componentes (lenguaje de control) Dos tipos Batch sequential Pipe and filter 32 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Batch Sequential Cada paso se ejecuta hasta ser completado, y recién después puede comenzar el siguiente paso. Usado en aplicaciones clásicas de procesamiento de datos 33 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Pipes and Filters Cada componente tiene inputs y outputs. Los componentes leen “streams” de datos de su input y producen streams de datos en sus outputs de forma continua. Filters: componentes que ejecutan las transformaciones Pipes: son los conectores que pasan los streams de datos de un filtro a otro 34 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Pipes and filters – Ventajas y Desventajas Pros Fácil de entender: la función del sistema es la composición de sus filtros Facilidad de extensión – reuso – recambio de filtros Posibilidad de ejecución concurrente Cons “Mentalidad batch”, difícil para aplicaciones interactivas El orden de los filtros puede ser complejo Overhead de parsing y unparsing Problemas con tamaño de los buffers Interesante: interfaces con XML, transformadas con XSL y con uso de herramientas de integración Extensiones: Bounded Pipes, Typed Pipes 35 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 “Call and Return” El estilo dominante en la mayoría de los sistemas Programa principal y subrutinas Programación estructurada Ventaja: concepto simple; desventajas: reuso limitado a funciones / procedimientos, limitada flexibilidad 36 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Call and Return (cont.) Arquitecturas orientadas a objetos Information hiding Encapsulamiento Herencia, polimorfismo Ventajas: reuso a gran escala, todas las ventajas del encapsulamiento (bien usado) y el information hiding, correspondencia en los objetos del dominio con objetos del mundo real. Desventaja principal: complejidad del código llevada al diseño Information hiding: las decisiones de diseño que es probable que cambien son ocultadas en un módulo o un conjunto pequeño de módulos (Parnas, 1972). 37 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Layered Cada nivel provee servicios Oculta en nivel siguiente Provee servicios al nivel anterior En muchos casos el “bajar” de nivel implica acercarse al hardware o software de base Los niveles superiores son “virtual machines” Ventajas: portabilidad, facilidad de cambios, reuso Desventajas: performance, difícil de encontrar la abstracción correcta, puede implicar salteo de niveles Useful systems Basic Utilities Core Level 38 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Client server Una instancia de un estilo más genérico: sistemas distribuidos Los componentes son clientes (acceden a servicios) y servidores (proveen servicios) Los servers no conocen la cantidad o identidad de los clientes Los clientes saben la identidad de los servidores Los conectores son protocoles basados en RPC Distintos “flavors” 39 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Componentes independientes Son arquitecturas de procesos que se comunican a través del envío de mensajes Componentes: procesos independientes Conectores: envío de mensajes Sincrónico o asincrónico Sistemas de eventos - Invocación implícita Implícita Ev1 C1 C2 C3 Explícita Op2 C1 Op1 Op1 Manager C3 C2 Op2 40 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Sistemas de eventos Modelo Componentes: procesos u objetos Las interfaces definen eventos que se pueden recibir Las interfaces definen eventos que se pueden anunciar Conexiones: “binding” de procedimientos a objetos Los componentes anuncian eventos Cuando se recibe un evento se ejecutan los procedimientos El orden de invocación no es determinístico Ventajas Se independiza la coordinación Facilita integración y evolución Se pueden paralelizar invocaciones (performance) Desventajas Dificutad de testear La indirección puede afectar la performance Intercambio de datos 41 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Arquitecturas centradas en datos Estructura de datos central (normalmente una base de datos) y componentes que acceden a ella. Gran parte de la comunicación está dada por esos datos compartidos. Normalmente presentes en todo sistema de información Dos tipos: blackboard y reposotorio (cada vez más “ocultos” en un esquema tipo “layered”) 42 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 State transition Generalmente un componente maneja la “maquina de estados” del sistema completo o de una parte de él. Generalmente con posibilidad de generación “dinámica” de nuevos estados y transiciones Con posibilidad de asignar código a ejecutarse al ocurrir un evento Posibilidad de usar una herramienta de Workflow Necesario en algunos sistemas, como por ejemplo en robótica 43 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Caso de Estudio: EEPS – End Effector Positioning Sofware Uno de los subsistemas de software del “Tessellator”, robot experimental para realizar mantenimiento en la protección térmica de los transbordadores espaciales de la NASA. El brazo móvil debe posicionar un plato con herramientas (cámara e inyector de impermeabilizante) bajo cada uno de los 17000 “azulejos” de protección térmica Principales requerimientos: Seguridad (“safety”): 1 – El robot no debe dañar físicamente al operador 2 – El robot no debe dañar la superficie del transbordador 3 – El robot no debe realizar ningún movimiento si el brazo está en una posición desconocida o inválida Funcionalidad: El sistema debe saber en todo momento la posición del brazo 44 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 EEPS - Arquitectura Componentes independientes comunicados por eventos Orientada a componentes que aíslan decisiones de diseño “information hiding” “State Machine”, que describe la posición del robot Arquitectura de referencia: 45 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Caso de Estudio – EEPS (cont.) State Manager: máquina de estados que conoce el estado del robot. Cinco procesos que corren en forma independiente y se comunican por mensajes asincrónicos. “Information hiding” para el manejo de posiciones y del detalle de las articulaciones División entre “sensors” y “actuators” 46 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
