Introducción a la Arquitectura de Software

Introducción a la Arquitectura de Software Billy ReynosoUNIVERSIDAD DE BUENOS AIRES Billyr@microsoft.com.ar

Objetivos • Suministrar una visión estructurada de la Arquitectura de Software contemporánea • No es pedagogía Arquitectura 101, sino más bien un survey de lo que significa AS, una evaluación de lo que ha llegado a ser y una puntualización sobre lo que no es • Despejar malos entendidos sobre arquitectura como diseño de aplicaciones • Vincular perspectivas de la academia y la industria • Privilegiar elaboraciones de la corriente teórica de CMU/SEI • Describir desarrollos de estado de arte, problemas pendientes y tendencias • Proporcionar referencias a recursos, documentación y herramientas • http://www.microsoft.com/spanish/msdn/arquitectura

Temario • Objetivos • Contexto • Errores de concepto habituales • Antecedentes históricos • Definición – Repositorio de definiciones • Corrientes principales • Conceptos fundamentales (CMU/SEI) • Estilos arquitectónicos • Estilos y patrones • Lenguajes de Descripción Arquitectónica (ADLs) • Atributos de calidad, escenarios y tácticas • Métodos basados en arquitectura • Situación, conclusiones y referencias

Contexto – 1995-2005 • Los 3 grandes temas de ingeniería de software • Patrones • Design patterns (GoF) - 1995 • Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides • Architectural patterns (POSA) - 1996 • Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal • Organizational patterns (Coplien) • Métodos heterodoxos (eXtreme Programming, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal, LD, ASD…) • Arquitectura de Software • Otros: • Refactorización • AOP, SOA, Grid Computing, Semantic Web...

Conceptos cuestionables (1/2) • Arquitectura como normativa madura • Abundancia de herramientas de diseño arquitectónico • Semántica y lenguajes arquitectónicos iguales en la academia y la industria • UML como lenguaje formal de modelado “arquitectónico” • Posición de la AS bien definida en ingeniería & ciclo de vida • Ocurre en algún punto entre la elicitación de requerimientos y la especificación de casos de uso, o entre éstos y el diseño • Arquitectura vinculada a metodología y proceso RUP • La AS está formalmente desarrollada las disciplinas de RUP (cf. Kazman, Kruchten et al 2004)

Conceptos cuestionables (2/2) • La AS tiene que ver con modelado OO • La AS no admite ni requiere otros paradigmas • No hay urgencia en considerar otros paradigmas (Berners-Lee) • Las herramientas arquitectónicas generan la estructura de la aplicación e incluso el código (analogía con modelos CASE) • El dilema del roundtrip engineering está resuelto • Hay que considerar modelo de DSL

Antecedentes históricos (1/5) • Edsger Dijkstra, 1968 • Ciencias de la computación como rama aplicada de las matemáticas • Niveles de abstracción • Stacks, abrazos mortales, semáforos, algoritmo de camino más corto • NATO, 1968 • F. L. Bauer “Ingeniería de software” • NATO, 1969 • P. I. Sharp, “Arquitectura de software” • C.R. Spooner, 1971 • “Una arquitectura de software para los 70s” • Referencia accidental

Antecedentes históricos (2/5) • Niklaus Wirth, 1971 • Niveles de abstracción Stepwise refinement • DeRemer & Kron, 1976 • Programming in the large • Fred Brooks, 1975 – MMM • Diseñador del OS/360, Premio Turing 2000 • Arquitectura como interfaz usuario • El arquitecto es un agente del usuario, igual que quien diseña su casa • Importancia de las estructuras de alto nivel y de decisiones tomadas al principio • Arquitectura: qué hacer - Implementación: cómo hacerlo

Antecedentes históricos (3/5) • David Parnas • 1972: Módulos – Ocultamiento de información • 1974: Estructuras de software • 1976: Familias de programas (Árbol de decisión) - Descomposición - Alternativa a diagramas de flujo, propensión estructural (no funcional) • “Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. Esto evita el uso de conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniería de software y los juegos de video no se consideran usualmente en el mismo dominio, aunque podrían considerarse miembros de la misma familia de programas en una discusión sobre herramientas que ayuden a construir interfaces gráficas, que ambos casualmente utilizan”.

Antecedentes históricos (4/5) • Línea de Dijkstra-Parnas-Hoare • Fundamentación matemática • Métodos formales • Programa fuerte • Línea de Brooks • Ambiente humano • Visión cualitativa • Pensamiento no lineal • Programa crítico y heterodoxo

Antecedentes históricos (4/5) • Dewayne Perry, Alexander Wolf – 1992 • “Foundations for the study of software architecture” • “La década de 1990, creemos, será la década de la arquitectura de software. Usamos el término “arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de estándares, de entrenamiento formal (de los arquitectos de software) y de estilo.  Es tiempo de re-examinar el papel de la arquitectura de software en el contexto más amplio del proceso de software y de su administración, así como señalar las nuevas técnicas que han sido adoptadas”. • Escuela de Carnegie Mellon (CMU-SEI) • Sin conexión explícita con CMMI® • Mary Shaw, David Garlan, Paul Clements, Robert Allen, Rick Kazman

Definición • http://www.sei.cmu.edu/architecture/definitions.html • (1) Proceso dentro del ciclo de vida, (2) Topología, (3) Disciplina. • Arquitectura - IEEE 1471-2000: • La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. • Adoptada por Microsoft en estrategia arquitectónica / MSF 3 & 4 • Ingeniería - IEEE 610.12.1990: • [La Ingeniería de Software es] la aplicación de una estrategia sistemática, disciplinada y cuantificable al desarrollo, aplicación y mantenimiento del software; esto es, la aplicación de la ingeniería al software.

Otras definiciones • Paul Clements, 1996: • “La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones”. • * Vista - * Componente

Desarrollos paralelos • Década de 1990: • Metáfora de patrones de C. Alexander (1977) • La Banda de los Cuatro (GoF), 1995 • POSA, 1996 • Desarrollo de UML / OOD

Corrientes teóricas en AS • Arquitectura como etapa de la ingeniería de software orientada a objetos • James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3 amigos”), Craig Larman… • Arquitectura estructural – SEI • Corriente principal: Garlan, Shaw, Clements • Variantes con modelos de datos (Medvidovic) • Variantes radicales, formales (Moriconi-SRI) • Arquitectura basada en patrones – SEI • Arquitectura procesual (Kazman, Bass)

Vistas • 1977, análisis estructurado (Douglas Ross) • Separación de incumbencias • Habitualmente 2 (funcional y de datos – ninguna aparece en AS) • La AS clásica no habla de vistas • Se basa en vista única e implícita, de carácter estructural • Muchos arquitectos evitan hablar de vistas • Cuando las vistas proliferan, se requieren lenguajes formales específicos para cada clase de vista • Las vistas son una abstracción conveniente, pero su abundancia involucra problemas de sincronización • En AS ortodoxa prevalecen 3: CC, concurrencia y despliegue (Bass, Clements, Kazman) • Lista corta (3 a 6) – Lista larga (8 o 9…) • Viewpoints’96

Conceptos fundamentalesVistas & frameworks

Vistas de UML… No hay componentes, ni conectores, ni constraints, ni configutraciones

Vistas de UML… • Vistas y puntos de vista no están homogeneizados en textos y autores • Cuando los “3” hablan de AS, las vistas no se refieren a viewpoints o concerns, sino a niveles de abstracción • Definición diferente de “arquitectura” • Interfaces en vez de conectores • Objetos en lugar de componentes (“elementos”) • Los conectores no son conectores de primera clase

Estilos Arquitectónicos • Rumbaugh-Booch-Jacobson 1991 • (1) transformaciones en lote, (2) transformaciones continuas, (3) interfaz interactiva, (4) simulación dinámica de objetos del mundo real, (5) sistemas de tiempo real, (6) administrador de transacciones con almacenamiento y actualización de datos • Pero: “estilos arquitectónicos”, “arquitecturas comunes”, “marcos de referencia arquitectónicos prototípicos”, “formas comunes”, “clases de sistemas” • Definición no exhaustiva • Criterios taxonómicos no homogéneos • Taxones de distinto nivel de inclusión • Algunos tipos pueden incluir otros (ej. 6 y 3)

Estilos arquitectónicos • Perry & Wolf, 1992 • Incluyen: • Componentes (2003, “elementos”) • Conectores • Estructuras (topologías, configuraciones) • Restricciones (constraints)

Estilos Arquitectónicos • Estilos de Flujo de Datos • Tubería y filtros • Estilos Centrados en Datos • Arquitecturas de Pizarra o Repositorio • Estilos de Llamada y Retorno • Model-View-Controller (MVC) • Arquitecturas en Capas • Arquitecturas Orientadas a Objetos • Arquitecturas Basadas en Componentes • Estilos Derivados • C2 • GenVoca • REST • Estilos de Código Móvil • Arquitectura de Máquinas Virtuales • Estilos heterogéneos • Sistemas de control de procesos • Arquitecturas Basadas en Atributos • Estilos Peer-to-Peer • Arquitecturas Basadas en Eventos • Arquitecturas Orientadas a Servicios (SOA) • Arquitecturas Basadas en Recursos

Tres ejemplos significativos • Arquitectura basada en eventos • Arquitectura de pizarra • Arquitecturas orientadas a servicios • Presentación separada en esta serie…

Arquitectura basada en eventos Impiden incurrir en el modelo de aplicaciones que preguntan si sucedió algo. Generan la ejecución apenas ocurre el evento o el usuario se conecta Modelo de push. A veces se vincula con patrón Observador (Observer pattern)

Arquitecturas de Pizarra

Arquitectura de Pizarra • H. Penny Nii, 1986 (Blackboard systems) • Cuándo se utiliza: Problemas no susceptibles de tratarse analíticamente • Reconocimiento de patrones, aprendizaje de máquina, data mining • Firmas, huellas digitales, reconocimiento de iris, rostro, etc • Dos formas: • Repositorio • Pizarra pura o tablero de control • Procesamiento de señales • Reconocimiento de habla • Redes neuronales, algoritmo genético, simulación de templado • Agentes autónomos (débilmente acoplados)

Estilos y patrones • POSA 96, Shaw 96 • Patrones: Christopher Alexander 1977 • Elementos que se repiten • Como un elemento en el mundo, cada patrón es una relación entre cierto contexto, cierto sistema de fuerzas que ocurre repetidas veces en ese contexto y cierta configuración espacial que permite que esas fuerzas se resuelvan. Como un elemento de lenguaje, un patrón es una instrucción que muestra la forma en que esta configuración espacial puede usarse, una y otra vez, para resolver ese sistema de fuerzas, donde quiera que el contexto la torne relevante • El patrón es, en suma, al mismo tiempo una cosa que pasa en el mundo y la regla que nos dice cómo crear esa cosa y cuándo debemos crearla. Es tanto un proceso como una cosa; tanto una descripción de una cosa que está viva como una descripción del proceso que generará esa cosa.

Comentario Problemas Soluciones Fase de Desarrollo Patrones de Arquitectura Relacionados a la interacción de objetos dentro o entre niveles arquitectónicos Problemas arquitectónicos, adaptabilidad a requerimientos cambiantes, performance, modularidad, acoplamiento Patrones de llamadas entre objetos (similar a los patrones de diseño), decisiones y criterios arquitectónicos, empaquetado de funcionalidad Diseño inicial Patrones de Diseño Conceptos de ciencia de computación en general, independiente de aplicación Claridad de diseño, multiplicación de clases, adaptabilidad a requerimientos cambiantes, etc Comportamiento de factoría, Clase-Responsabilidad-Contrato (CRC) Diseño detallado Patrones de Análisis Usualmente específicos de aplicación o industria Modelado del dominio, completitud, integración y equilibrio de objetivos múltiples, planeamiento para capacidades adicionales comunes Modelos de dominio, conocimiento sobre lo que habrá de incluirse (p. ej. logging & reinicio) Análisis Patrones de Proceso o de Organización Desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización Productividad, comunicación efectiva y eficiente Armado de equipo, ciclo de vida del software, asignación de roles, prescripciones de comunicación Planeamiento Idiomas Estándares de codificación y proyecto Operaciones comunes bien conocidas en un nuevo ambiente, o a través de un grupo. Legibilidad, predictibilidad. Sumamente específicos de un lenguaje, plataforma o ambiente Implementación, Mantemimiento, Despliegue

Usos de estilos • Mary Shaw, David Garlan, 1996 • Inspirado en trabajo de Parnas, 1972 (“On the criteria to be used in decomposing systems into modules”) – Datos compartidos vs ocultamiento de información • Sistema de indexación de palabras claves • Datos compartidos • Tipos abstractos de datos • Invocación implícita • Tubería y filtros • Comparación de versatilidad, dependencia, modularidad, reutilización, refinamiento, ventajas & desventajas • Antes de escribir una línea de código • Tablas de comparación de atributos • Asignación de pesos a prioridades

Estilos - Conclusiones • Después de 13 años, son menos conocidos y frecuentados que los patrones • Son fundamentales para la toma de decisiones del diseño, ya que se dispone de métodos comparativos que no existen para el caso de los patterns • Metodologías SACAM, CBAM • Es esencial que se conserve un número pequeño de estilos disponibles

Requerimientos no funcionales Performance Disponibilidad Modificabilidad Seguridad Verificabilidad (Testability) Gestionabilidad (instrumentación, management, estado) Usabilidad

Atributos de Calidad

Escenarios • Equivalente no funcional de los casos de uso • No contemplados en UML / RUP • Cuantificables - No hay diagramas de escenarios • Estímulo, ambiente, respuesta • Escenario de caso de uso: • Un usuario remoto de web requiere un reporte de base de datosen hora pico y lo recibe dentro de los 5 segundos. • Escenario de crecimiento: • Agregar un nuevo servidor de base de datospara reducir latencia en escenario 1 a 2.5 segundosdentro de una persona-semana. • Escenario exploratorio: • La mitad de los servidores se bajarádurante operación normalsin afectar la disponibilidad del sistema.

Lenguajes de Descripción Arquitectónica (ADLs) • Lenguajes para el modelado, la descripción y (eventualmente) la prueba de la arquitectura • Representación de componentes, conectores, configuraciones y restricciones • Prueba de consistencia arquitectónica • Soporte de evolución

Géneros emparentados Lenguajes de especificacíón (LARCH, Z) Lenguajes de prototipado (Modechart, PSDL) Lenguajes de modelado (UML) Lenguajes de programación (CODE, Ada) Herramientas para definición de ciclo de vida (UNAS/SALE)

Acme/Armani

ADLs: Sustento formal • Darwin: cálculo Pi (Milner-Parrow-Walker) • BizTalk primitivo, Polyphonic C# • Wright: Communicating Sequential Processes (CSP), lógica de primer orden • LILEANNA: programación parametrizada e hiper-programación • Rapide: Posets • SAM: Redes de Petri de transición de predicados, lógica temporal de primer orden • Jacal: Redes de Petri • Casi todos los ADLs tienen BNF • Modelo estructural no ligado a OO

Situación actual de los ADLs • Ninguno se impuso ni en la academia ni en el mercado • Compás de espera: • UML 2 • Domain Specific Languages • XML • Web Semántica • Visión positiva: necesidad de métodos formales debido a complejidad de factores • Visión negativa: ADLs “obsoletos” • La producción de ADLs se ha desacelerado

Posicionamiento en ciclo de vida (AS en RUP) Atributos de calidad & escenarios [Primitivas de atributo] Architecture Based Design (ABD) Tácticas Arquitectónicas Comparación de alternativas (SACAM) Diseño basado en atributos (ADD) Ventajas y desventajas (ATAM) Elección de arquitectura Análisis de arquitectura (SAAM) Quality Attribute Workshop (QAW) Revisión activa de diseño parcial (ARID) Análisis de costo/beneficio (CBAM) Reformulación: UML & RUP Metodologías arquitectónicas

Campos de AS • Fundamentos formales de la AS • Bases matemáticas • Caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidad • Teorías de la interconexión • Técnicas arquitectónicas de análisis • Métodos de desarrollo basados en arquitectura • Visual Studio 2005 Team System • Recuperación y reutilización de arquitectura • Codificación y guía arquitectónica • Herramientas y ambientes de diseño arquitectónico • Estudios de casos

Problemas pendientes en AS • Falta de criterio unificado • No hay un modelo de proceso de punta a punta • Desarrollo en paralelo de conceptos antagónicos o no coordinados • Métodos ágiles • Metodologías de ciclo de vida • Patrones, estilos y tácticas • Apropiación nominal de la AS por estrategias que no implementan principios arquitectónicos pero se benefician de su prestigio • Poca masa crítica de herramientas y lenguajes de modelado arquitectónico (de alto nivel, con conectores de primera clase)

Beneficios • Decisiones tempranas • Barry Boehm, 1995 • Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su justificación, el proyecto no debe empezar el desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la puede usar a lo largo de los procesos de desarrollo y mantenimiento [Boe95]. • Análisis de consistencia antes de elaborar el diseño (y escribir el código) • Sistematización de la experiencia • Homogeneización del lenguaje (IEEE 1471) • Herramientas para la evolución • Re-utilización

Conclusiones generales Importancia de la Arquitectura de Software Criticidad de las decisiones tempranas de arquitectura Alto nivel de abstracción Vinculada con requerimientos no funcionales Fuerte impulso en la academia y la industria Herramientas arquitectónicas aún en proceso de definición y desarrollo Metodologías arquitectónicas, en proceso de elaboración preliminar Resta elaborar: tácticas arquitectónicas, métodos basados en arquitectura, vínculo entre conceptos de arquitectura, DSLs, factorías, building blocks, …

Referencias • Artículos de Arquitectura de Software en http://www.microsoft.com/spanish/msdn/arquitectura • Len Bass, Paul Clements, Rick Kazman. 2003. Software Architecture in Practice, 2ª edición • Documentación del SEI en Carnegie Mellon • http://www.sei.cmu.edu/publications/publications.html • Rick Kazman, Philippe Kruchten et al. 2004. “Integrating Software-Architecture-centric methods into the Rational Unified Process”, CMU/SEI-2004-TR-011 • Recomendaciones IEEE 1471/2000

¿Preguntas? Billyr@microsoft.com.ar

Introducción a la Arquitectura de Software