Post on 09-Jul-2015
Architect Academy:Seminario de Arquitectura de Software
Billy ReynosoUNIVERSIDAD DE BUENOS AIRES
Billyr@microsoft.com.ar
Roadmap
Webcast #1: ¿Qué es la Arquitectura de Software?
Webcast #2: Drilldown en Estilos de Arquitectura
Webcast #3: Arquitectura para distribución y agregación: Services Oriented Architecture (SOA)
Webcast #4: Diseñando la arquitectura
¿Qué es la Arquitectura de Software?
Objetivos del curso
Breve historia y definición
Principales conceptos arquitectónicos
• Estilos de arquitectura: componentes, conectores, restricciones (constraints), configuraciones
• Diseñar para calidad de desarrollo: Estilos y Patrones
• Puntos de vista arquitectónicos: componente, concurrencia, despliegue
• Requerimientos no funcionales: Tácticas y frameworks de conocimiento
• Más allá de los casos de uso: Escenarios y atributos de calidad
• Lenguajes de Descripción Arquitectónica (ADLs)
Arquitectura, razonamiento de alto nivel y calidad operacional: Ejemplo canónico de práctica arquitectónica (Garlan & Shaw)
Objetivos del curso
Clarificar el carácter distintivo de la Arquitectura de Software
Proporcionar lineamientos y recursos para la práctica arquitectónica
Vincular visiones de la academia y la industria
Establecer situación actual y perspectivas, con énfasis en las herramientas, middleware y sistemas operativos de Microsoft
Contexto
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 (2001)
eXtreme Programming, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal, LD, ASD…)
• Arquitectura de Software (1992)
Surgimiento
1969 – Conferencia OTAN
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)
• Mary Shaw, David Garlan, Paul Clements, Robert Allen Bibl…
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
Ingeniería - IEEE 610.12.1990:
• 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.
La Arquitectura no es…
Una normativa madura
Igual en la academia y en la industria
Diseño de software con UML
Naturalmente vinculada con 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
Naturalmente vinculada a metodología (RUP)
Naturalmente relacionada con modelado Orientado a Objetos
Hay vínculo “natural” entre requerimientos (casos de uso) y clases
Las herramientas arquitectónicas generan el código de la aplicación
Arquitectura es…
Vista estructural de alto nivel
Define estilo o combinación de estilos para una solución
Se concentra en requerimientos no funcionales
• Los requerimientos funcionales se satisfacen mediante modelado y diseño de aplicación
Esencial para éxito o fracaso de un proyecto
Corrientes principales
Arquitectura estructural – SEI – Carnegie Mellon
• Garlan, Shaw, Clements
• Variantes con modelos de datos (Medvidovic), radicales, formales (Moriconi-SRI), etc
Arquitectura como etapa de la ingeniería de software orientada a objetos
• James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3…”), Craig Larman…
Arquitectura basada en patrones – SEI
• Redefinición de estilos como patrones POSA
• Microsoft Patterns & Practices
Arquitectura procesual y metodologías
• Kazman, Bass (SEI)
• Variantes de arquitectura basada en escenarios
Estilos Arquitectónicos
Rumbaugh & al 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”
Estilos – Nueva concepción
Perry & Wolf, 1992
Componentes (ahora: Elementos)
Conectores
Configuraciones
Restricciones (Constraints)
“Mano mágica” (Fielding, 2000)
UML?
Estilos ArquitectónicosEstilos 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 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
• Arquitecturas Basadas en Recursos
Estilos derivados
C2
GenVoca
REST
Estilos
Sirven para sintetizar estructuras de soluciones
Pocos estilos abstractos encapsulan una enorme variedad de configuraciones concretas
Definen los patrones posibles de las aplicaciones
Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante diferentes conjuntos de requerimientos no funcionales
Ejemplo
Mala práctica:
• Aplicaciones clientes que consultan si sucedió algo
• Listener de HTTP, Archivo, Colas
Buena práctica:
• Estilo basado en Eventos
EjemploArquitectura basada en eventosModelo de push a veces se vincula con patrón Observador (Observer pattern)
Arquitectura basada en eventos Ventajas
• Simplicidad
• Evolución: se pueden reemplazar componentes suscriptores
• Modularidad: una sola modalidad para eventos diversos
• Puede mejorar eficiencia, eliminando la necesidad de polling por ocurrencia de evento
Desventajas
• Posibilidad de desborde
• Potencial imprevisión de escalabilidad
• Pobre comprensibilidad: Puede ser difícil prever qué pasará en respuesta a una acción
• No hay garantía del lado del publisher que el suscriptor responderá al evento
• No hay mucho soporte de recuperación en caso de falla parcial
Arquitectura basada en eventos
Dos modelos de arquitectura e implementación
Tightly coupled events (TCE, eventos fuertemente acoplados)
• P. ej. COM Connection Points.
• Requiere que ambos componentes estén corriendo simultáneamente. No hay forma de filtrar evento (p. ej. cuando acción alcance cierto valor)
• Requiere conocer ambas interfaces específicas
Losely coupled events (LCE, eventos débilmente acoplados)
• P. ej. COM+ Events
• Almacenamiento de eventos (COM+ Catalog)
• Referencia: MSDN Library – COM+ Technical Series: Losely coupled events
Arquitectura basada en eventos Permiten invocación implícita de una herramienta cuando otra
herramienta produce un evento
También se llama Invocación implícita
• Un componente anuncia un evento. Otros registran interés en ese tipo de evento. Cuando se produce, el sistema (la “mano invisible”) lo comunica a los suscriptores.
Algunos incluyen a MVC en esta clase
Modelo Publish / Subscribe
MS: Registración de Eventos COM+, eventos (listeners) de BizTalk Server, Notification Service de SQL Server
Demo
Arquitectura basada en eventos
Herramientas en ambiente COM+/.NET
En muchos casos no se requiere programación de bajo nivel
También hay profusión de herramientas programáticas y servicios de “mano mágica”
Administrative tools
• Component Services
COM+ Applications
.NET Utilities, Biztalk Server/Interchange
Relación entre Estilos y Patrones (Patterns)
Patterns
Christopher Alexander, 1977
Un patrón es una solución a un problema en un contexto
Un patrón codifica conocimiento específico acumulado por la experiencia en un dominio
Un sistema bien estructurado está lleno de patrones
Patterns - Alexander
“Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esa solución un millón de veces más, sin hacer jamás la misma cosa dos veces.”
Ejemplos: galería, paseo, patio compartido, columnata, estacionamiento
Elementos de un patrón Nombre
• Define un vocabulario de diseño
• Facilita abstracción
Problema
• Describe cuando aplicar el patrón
• Conjunto de fuerzas: objetivos y restricciones
• Prerrequisitos
Solución
• Elementos que constituyen el diseño (template)
• Forma canónica para resolver fuerzas
Consecuencias
• Resultados, extensiones y tradeoffs
MVC
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
IdiomasEstá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
Organización de Patrones Propuesta por MS para Enterprise Solution Patterns Using
Microsoft .NET (ESP)
Propósito:
• Identificar relaciones entre patrones
• Agrupar patrones en clusters
• Identificar patrones a diversos niveles de abstracción
• Aplicar patrones a múltiples aspectos de una solución
• Organizar patrones en un frame
• Usar patrones para describir en forma concisa una solución…
Ejemplos de ESP
Niveles de abstracciónVistas
Frame
Documento
Requerimientos no funcionalesEscenarios, tácticas, frameworks
Performance
Disponibilidad
Modificabilidad
Seguridad
Verificabilidad (Testability)
Gestionabilidad (instrumentación, management, estado)
Usabilidad
Atributos de Calidad
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.
Ejemplo de metodología Refinamiento de Escenario
Los escenarios se refinan considerando:
• 1. Estímulo - La condición que afecta al sistema
• 2. Respuesta - La actividad que resulta del estímulo
• 3. Fuente del estímulo - La entidad que lo genera
• 4. Ambiente - La condición bajo la cual el estímulo ocurre
• 5. Artefacto estimulado
• 6. Medida de respuesta - Para evaluar la respuesta del sistema
Se describen los objetivos de negocio/misión afectados por el escenario y las cualidades relevantes asociadas con él
En funcíón de los escenarios se pueden evaluar los estilos arquitectónicos que pueden satisfacer los requerimientos
Lenguajes de Descripción Arquitectónica (ADLs)
Componentes
Conectores
Configuraciones o sistemas
Propiedades no funcionales
Restricciones
Estilos
Evolución
Herramientas de verificación
ADL Fecha Investigador - Organismo ObservacionesAcme 1995 Monroe & Garlan (CMU), Wile (USC) Lenguaje de intercambio de ADLsAesop 1994 Garlan (CMU) ADL de propósito general, énfasis
en estilosArTek 1994 Terry, Hayes-Roth, Erman
(Teknowledge, DSSA)Lenguaje específico de dominio -No es ADL
Armani 1998 Monroe (CMU) ADL asociado a AcmeC2 SADL 1996 Taylor/Medvidovic (UCI) ADL específico de estiloCHAM 1990 Berry / Boudol Lenguaje de especificaciónDarwin 1991 Magee, Dulay, Eisenbach, Kramer ADL con énfasis en dinámicaJacal 1997 Kicillof , Yankelevich (Universidad de
Buenos Aires)Adl - Notación de alto nivel paradescripción y prototipado
LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexión de módulosMetaH 1993 Binns, Englehart (Honeywell) ADL específico de dominioRapide 1990 Luckham (Stanford) ADL & simulaciónSADL 1995 Moriconi, Riemenschneider (SRI) ADL con énfasis en mapeo de
refinamientoUML 1995 Rumbaugh, Jacobson, Booch (Rational) Lenguaje genérico de modelado –
No es ADLUniCon 1995 Shaw (CMU) ADL de propósito general, énfasis
en conectores y estilosWright 1994 Garlan (CMU) ADL de propósito general, énfasis
en comunicaciónxADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML
Métodos basados en Arquitectura
Architecture Tradeoff Analysis Method (ATAM)
Quality Attribute Workshops (QAW)
Attribute-Driven Design (ADD)
Active Reviews for Intermediate Designs (ARID)
Cost-Benefit Analysis Method (CBAM)
Software Architecture Comparison Analysis Method (SACAM)
Quality-Attribute-Driven Software Architecture Reconstruction (QADSAR)
Architecture Based Design Method (ABD)
Software Architecture Analysis Method (SAAM)
Usos de estilos
Mary Shaw, David Garlan, 1996
• IEEE98SA-Styles-Patterns.pdf
• 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
Paper
Síntesis
Arquitectura:
Visión de alto nivel
Estilo - Patrón
Previo a diseño de aplicación
Requerimientos no funcionales
Escenarios
Lenguajes de descripción arquitectónica
Referencias
Len Bass, Paul Clements, Rick Lazman. Software Architecture in Practice, 2a edición, Addison-Wesley, 2003
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal. Pattern Oriented Software Architecture, vol. 1. Wiley, 1996
Documentos en http://www.microsoft.com/spanish/msdn/Arquitectura
Docs…
Webcast # 2 – Drilldown en estilos de arquitectura
Diseñar desde arriba: La especificidad de la abstracción arquitectónica
Estilos: historia, definición, inventario
Estilos fundamentales
Práctica arquitectónica
Implementando estilos con Windows services, Middleware MS y .NET Framework
¿Preguntas?
http://www.microsoft.com/spanish/msdn/arquitectura
Billyr@microsoft.com.ar