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 anterior | Volver al principio del trabajo | Página siguiente  |