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.
(Gp:) Comentario
(Gp:) Problemas
(Gp:) Soluciones
(Gp:) Fase de Desarrollo
(Gp:) Patrones de Arquitectura
(Gp:) Relacionados a la interacción de objetos dentro o entre niveles arquitectónicos
(Gp:) Problemas arquitectónicos, adaptabilidad a requerimientos cambiantes, performance, modularidad, acoplamiento
(Gp:) Patrones de llamadas entre objetos (similar a los patrones de diseño), decisiones y criterios arquitectónicos, empaquetado de funcionalidad
(Gp:) Diseño inicial
(Gp:) Patrones de Diseño
(Gp:) Conceptos de ciencia de computación en general, independiente de aplicación
(Gp:) Claridad de diseño, multiplicación de clases, adaptabilidad a requerimientos cambiantes, etc
(Gp:) Comportamiento de factoría, Clase-Responsabilidad–Contrato (CRC)
(Gp:) Diseño detallado
(Gp:) Patrones de Análisis
(Gp:) Usualmente específicos de aplicación o industria
(Gp:) Modelado del dominio, completitud, integración y equilibrio de objetivos múltiples, planeamiento para capacidades adicionales comunes
(Gp:) Modelos de dominio, conocimiento sobre lo que habrá de incluirse (p. ej. logging & reinicio)
(Gp:) Análisis
(Gp:) Patrones de Proceso o de Organización
(Gp:) Desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización
(Gp:) Productividad, comunicación efectiva y eficiente
(Gp:) Armado de equipo, ciclo de vida del software, asignación de roles, prescripciones de comunicación
(Gp:) Planeamiento
(Gp:) Idiomas
(Gp:) Estándares de codificación y proyecto
(Gp:) Operaciones comunes bien conocidas en un nuevo ambiente, o a través de un grupo. Legibilidad, predictibilidad.
(Gp:) Sumamente específicos de un lenguaje, plataforma o ambiente
(Gp:) 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 datos en hora pico y lo recibe dentro de los 5 segundos. Escenario de crecimiento: Agregar un nuevo servidor de base de datos para reducir latencia en escenario 1 a 2.5 segundos dentro de una persona-semana. Escenario exploratorio: La mitad de los servidores se bajará durante operación normal sin 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
Metodologías arquitectónicas 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
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, .
| Página siguiente |