Arquitectura de Software V: Prácticas Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María <hernan at acm.org> Introducción, motivación y contexto Representación de arquitecturas Elaboración de arquitecturas Principios y evaluación de arquitecturas Prácticas de arquitectura Políticas y Mecanismos Re-visitando un ejemplo complejo Componentes y Organizaciones Terminología de Mercado Estandarización La profesión Enseñando Arquitectura de Software Contenido del curso 2 1
V: Prácticas de arquitectura Políticas y mecanismos Re-visitando un ejemplo complejo Componentes y organizaciones Terminología del mercado Estandarización La profesión Enseñando Arquitectura de Software 3 Políticas y mecanismos 2
Idea: Políticas y mecanismos identificar y separar dimensiones Fundamento teórico Diferentes niveles de abstracción Ejecutar ( realize ) políticas con mecanismos disponibles 5 Descripción del proceso: Ejemplo: e-mail Escritor de correo prepara mensaje en cliente, y envía al lector, quien lee el mensaje en su cliente de correo Implementación conocida por nosotros: vía Internet Modelo: caso de uso, diagrama de secuencia, etc. Nuestro interés: refinar el modelado de la comunicación Dimensiones de interés de la comunicación (en este ejemplo): Sincronía: síncrona vs. asíncrona Entrega: push vs. pull Topología: broadcast vs. multicast 6 3
e-mail: Sincronía [1/2] Modelo informal 2 personas asíncronos 2 clientes idem versión Internet: Clientes y servidores entre sí: TCP/IP síncrono versión con filas: Clientes y servidores entre sí son asíncronos 7 e-mail: Sincronía [2/2] Interesante: al refinar versión Internet... TCP/IP realizado por paquetes asíncronos 8 4
e-mail: Entrega [1/2] Modelo informal sender receiver toma push pull me de usos: push : entrega cuando el enviador quiere pull : entrega cuando el receptor quiere 9 e-mail: Entrega [2/2] Modelo UML (hacer in situ) 10 5
Modelo informal e-mail: Topología [1/2] multicast vs. broadcast (1:M especificados) vs. (1:todos en la red) 11 e-mail: Topología [2/2] Disonancia cognitiva Multicast puede ser implementado con broadcast Receptores que no debían escuchar ignoran el mensaje Requiere cambio en cada receptor Broadcast puede ser implementado con multicast Mantener catálogo de escuchadores Necesita cambio en cada receptor y catálogo Moraleja Mala opción inicial de política no impide buena solución Pero requiere trabajo adicional (tal vez sustancial) 12 6
Resumiendo Distinguir políticas y mecanismos roles en un proceso/descripcion de refinamiento Una solución que es mecanismo en un nivel de abstracción es política en el nivel inferior (política y mecanismo son roles en una relación entre elementos de diferentes niveles de abstracción) En general, una implementación puede ser documentada pero no computada UML: «trace», «derive» 13 Componentes y organizaciones 7
Arquitectura de aplicaciones Escalas de arquitectura aplicación o sistema (colaboración de aplicaciones) Arquitectura de línea de productos Framework para un dominio Arquitectura de referencia definen vocabulario y permiten intercambio ínter-organizacional CORBA,.NET... 15 Componente [Whitehead] Componentes Pieza separable (independiente del contexto) de software ejecutable...que tiene sentido como unidad...y puede interoperar con otros componentes...dentro de un ambiente de apoyo...y es accesable sólo vía sus interfaces...y está listo para usar (posiblemente requiriendo instalación y configuración) Fuentes de componentes Dominio (entidades, propiedades...) Interfaces Capas de abstracción ( máquinas virtuales ) Instanciaciones de arquetipos 16 8
Interoperabilidad Problema: cooperación entre componentes Número exponencial de pares Se complica al introducir más de una tecnología Mecanismos estandarizados para describir interfaces CORBA IDL COM IDL Interoperabilidad entre tecnologías Modelos de componentes COM, CORBA, EJB Wrappers (envoltorios) Servicios Propiedades transaccionales Manejo de seguridad Monitoreamiento 17 Modelos de componentes [1/3] Modelos de componentes distribuidos (clientes y servidores) COM: Common Object Model (Microsoft; en.net) CORBA: Common ORB Architecture (OMG: Object Management Group) ORB: Object Request Broker Java (Sun, JCP) Modelos extendidos para mejor apoyar servidores MTS (Microsoft Transaction Service) CCM (CORBA Component Model) EJB (Enterprise Java Beans) J2EE (Java 2 Enterprise Edition) 18 9
Modelos de componentes [2/3] Modelos extendidos con soporte adicional Manejo transaccional Seguridad Persistencia Disponibilidad Clustering, balanceo de carga Ambiente de ejecución Ciclo de vida (instanciación, GC...) Threading Pooling de conexiones Manejo de estado Monitoreamiento dinámico 19 Modelos de componentes [3/3] Servicios Location (ubicación) detección de componentes/servicios; análogo a guía telefónica JNDI (Java Naming & Directory Interface) CORBA Naming Service & Trading Service Manejo de transacciones autenticación, autorización, inviolabilidad, no-repudiación CORBA Security Service JAASL Java Authentication & Authorization Service Eventos, notificaciones & mensajería Mensajes asíncronos, point-to-point & publish-subscribe CORBA Notification (& Event) Services, Messaging Service JMS: Java Messaging Service 20 10
Organizaciones para arquitectura Quién es responsable de hacer/gestionar arquitectura? Idea: asociar escalas de arquitectura a niveles de la organización [Jacobson/Griss/Jonsson] 3 niveles: Empresa Departamento (unidad) Proyecto Se delega autoridad, pero no responsabilidad Estandarizar vía lenguaje compartido arquitectura de referencia patrones y estilos 21 Organizaciones para componentes Problema: propiedad y control de componentes Pueden no calzar con las unidades organizacionales Control de cambios Redundancia Soluciones Reestructurar la organización Imponer propiedad y/o factorización Mercado interno de componentes Decidir quién paga el costo de hacer casos generales Decidir quién paga cambios específicos Decidir modelo de propagación de cambios a los afectados Propiedad: unidades de negocio vs. centralizada 22 11
Terminología de mercado 2 capas: cliente-servidor Razón: concentrar recursos escasos en servidores centralizados Redundancia mínima Rendimiento puede sufrir Autonomía mínima 2 Capas 24 12
3 capas 3 capas Razón: compartir datos, preservando integridad (ACID) Negocio : procesamiento propio del negocio 2 partes: objetos de negocio (entidades del dominio) y lógica de control (funciones) Presentación : interacción con usuarios (incl. informes) y otros sistemas Datos : manejo de datos persistentes (incl. integridad) 25 4 capas 26 13
4 capas (Cont.) Usuario : mecanismos de interacción con usuarios y otros sistemas Workspace : manejo de sesiones y transacciones Negocio (empresa): procesos y entidades del negocio Recursos : elementos únicos compartidos (BD, sistemas legado, servicios) 27 Categorías de productos Empaquetados por tipo de problema y tipo de solución Tipos de solución: tecnologías Middleware Productos MOM, BD, directory servers, TP Monitors, workflow... Tipos de problemas: servicios del negocio Paquetes ERP (Enterprise Resource Planning), CRM (Customer Relationship management) y variaciones, Knowledge Management... 28 14
Middleware Middleware : tecnologías para comunicar programas distribuidos Britton propone clasificar middleware usando 8 aspectos de la comunicación Transporte (enlace) (ej: TCP/IP) Protocolo (ej: HTTP) API (ej: ODBC) Formato (ej: ASCII) Control de recursos en el servidor (ej: MTS) Directorios/nombres (ej: DNS) Seguridad (ej: Kerberos) Administración 29 Middleware - Dimensiones Participantes en la comunicación programas/objetos cada vez más pequeños y numerosos IP (hardware), TCP (procesos), IIOP (objetos) Modo de comunicación sesiones: protocolos con o sin ellas TCP (IP con sesión), UDP (IP sin sesión) topología: 1:M, peer-to-peer, M:1 iniciador: push, pull integridad vs. puntualidad ( timeliness ) Interfaz con API: número fijo de entradas con IDL: mecanismo para definir API ad-hoc 30 15
Servicios Web Integración usando infraestructura Web/Internet Aspectos Transporte Formato Búsqueda Soluciones empaquetadas (aún en desarrollo) Web services SOAP (Simple Object Access Protocol): HTTP + XML WSDL (Web Service Description Language) UDDI (Universal Description, Discovery and Integration) REST: Representational State Transfer HTTP + URL + XML/HTML/GIF/MIME/etc. (sin directorios) CORBA: IIOP + marshalling + Directory/Trader Service 31 Catálogos Catálogos de arquitectura Ingenieros tienen catálogos de partes disponibles con especificaciones de contexto, parámetros... Necesarios para centralizar y difundir información Fundamento teórico propuesto Clasificar Middleware Análisis de dimensiones aún pendiente Políticas y mecanismos Enfoque análogo 32 16
Estandarización Estandarización Vasta cantidad de STLs OMG OMA-RM MDA ECA 34 17
OMG: Object Management Group Consorcio industrial (600+ miembros) Propósitos: establecer guías para la industria crear especificaciones para administración de objetos proveer un marco común para desarrollar aplicaciones OMG OMA: Object Management Architecture infraestructura conceptual para las especificaciones del OMG OMA-RM: OMA Reference Model 35 ORB: Object Request Broker OMA-RM [1] medio transparente para pedidos y respuestas en un ambiente distribuido especificación: CORBA Common ORB Architecture Servicios de Objetos servicios (interfaces y objetos) con funciones básicas para implementar objetos distribuidos especificación: CORBAservices ejemplos: Ciclo de Vida, Persistencia 36 18
Facilidades Comunes servicios comunes pero no fundamentales especificación: CORBAfacilities ejemplos: administración, e-mail Objetos Aplicaciones aplicaciones (únicas por definición) OMA-RM [2] 37 Técnicas para desarrollar aplicaciones MOF: Meta-Object Facility UML: Unified Modeling Language MDA: Model-Driven Architecture Modelado OMG 38 19
CIM: Computing Independent Model modelo de negocio PIM: Platform Independent Model arquitectura sin referencia a tecnología específica PSM: Platform Specific Model arquitectura en términos de una plataforma específica PM: Platform Model ISM: Implementation Specific Model MDA [1] arquitectura en términos de una implantación específica 39 MDA [2] Idea: a partir de modelos abstractos, refinar a modelos concretos usando meta -modelos PM: Platform Model permite refinar PIM a PSM 40 20
ECA ECA: Enterprise Collaboration Architecture CCA: Component Collaboration Architecture consiste de Process Components Modelo de Entidades Modelo de Eventos Modelo de Proceso de Negocio especializa el CCA 41 La profesión 21
Otros sentidos de arquitectura [1] Por ámbito: Enterprise Architecture : visión y principios transversales en la empresa p.ej. seguridad, flexibilidad, políticas de compra, reuso Arquitectura de Dominio: específica a un área Arquitectura de Línea de Productos: definiciones comunes a productos (diseño y/o implementación) Arquitectura de Referencia: vocabulario (estilo y componentes) para dominios de aplicación 43 Otros sentidos de arquitectura [2] Por tipo de preocupación: Arquitectura de Negocio: estrategias, organización y metas para procesos de negocios Arquitectura de Aplicaciones: políticas para y soluciones de software a problemas específicos Arquitectura Técnica (o Infraestructura): soluciones generales y/o estandarizadas (redes, plataformas...) Arquitectura de Datos (o Información): almacenamiento y manejo de información (propiedad, diseño, métodos...) 44 22
Metáfora de arquitecto Metáforas y modelos más adecuada: edificio, no casa justificar preguntas: así como el arquitecto del edificio puede justificar sus preguntas, debemos poder justificar las nuestras Calidad de los modelos: casas: maquetas (modelos analógicos), levantamientos, planos... sistemas: vistas, diagramas... Apuesta de la disciplina: con el tiempo, nuestros modelos mejorarán programa 1 de mejoramiento: ADLs programa 2: vistas ( programa de investigación como en filosofía de la ciencia) 45 leer una performance sintaxis: gestos razones: historia detrás criticar hacer reflexionar *** Teatro Japonés *** 46 23
Técnicas del arquitecto [bis] Problema Elaboración concurrente de modelos para múltiples aspectos Técnicas clave Refinamiento Múltiples niveles de abstracción y completitud Descripción en capas Capas son modelos incompletos, pero comprensibles Refinamiento derivable Refactoring (factorización) 47 La gran ility : Rastreabilidad [bis] Noción fundamental de arquitectura Rastreabilidad: propiedad de un modelo que permite relacionar una decisión con su justificación e implicaciones Permite estudiar impacto de cambios (forward) y razones para acción propuesta (backward) Los modelos deben proveer información Refinamiento: explicado o aparente Niveles de abstracción : mapeables entre sí Una buena arquitectura cuenta una historia Explicar no sólo el que y como, sino el porqué Permite decisiones informadas a futuro 48 24
Enseñando Arquitectura de Software Analogías y educación Analogías desde la industria de construcción El arquitecto de software como arquitecto El diseñador o programador como constructor Analogías desde la industria cinematográfica El arquitecto del proyecto es el director de la película El jefe del proyecto es el productor de la película Formas de educación (y socialización) En estudios: como los abogados y los arquitectos Aprender mirando por encima del hombro En clínicas: como los médicos Aprender en equipo en modo crisis Pasiva: como los ingenieros Cursos teóricos, práctica post-graduación 50 25
4 niveles de competencia Lectura de arquitecturas Poder usarlas como guía de acción Lectura crítica de arquitecturas Poder evaluarlas y modificarlas Elaboraci ón de arquitecturas Poder elaborar sistemas y descripciones de ellos Reflexión crítica sobre la disciplina Poder reflexionar más allá de lo operacional Ojo: no implica ser investigador Formatos de entrega Secuencial vs. iterativo-incremental Qué unidades usar? Modelo docente 51 Formato modelo aplicado aquí Estructura de esta charla Sólo los 3 primeros niveles conceptos superficiales (lectura no accionable) Entrega secuencial, sin iteraci ón Nivel de competencia impartido bottom-up ejemplos someros y recibidos, no elaborados Algunas técnicas específicas Problematizaci ón inicial remover nociones previas, definir lo que no es arquitectura Uso de casos ejemplo seguido con complejidad incremental diálogo <flujo principal>-< sidebars > (introduciendo temas) Restricciones clave tiempo: permitir reflexión dedicación: audiencia mixta 52 26
Formatos modelos para cursos Relajando restricciones: modelos posibles Casos: proyectos desarrollados en paralelo (entrelazados) Modelo: aprendiz (como abogados, médicos, arquitectos) Disyuntiva: formar arquitectos o investigadores Casos límite: cuánto tiempo y esfuerzo dedicar? Posibles extensiones Lectura crítica y elaboración: evaluaci ón y comparación soluciones alternativas de mercado a problema dado Reflexión: problemas aún abiertos derivación de arquitecturas desde requisitos sistémicos descripción de políticas, mecanismos, y realización relación derivación capas (derivación aparente vs. real) 53 Conclusión 27
Un modelo o un diagrama? 55 Reconocimiento reciente de la disciplina Dicotomía teoría-práctica Procesos, métodos y técnicas: aún madurando Arquitectos describen sistemas En forma que permita su evaluación a priori Y que permiten armar procesos para construirlos Rol fundamental: stakeholders Noción de calidad depende de ellos Las arquitecturas son medios (de comunicación y educación) El arquitecto es el director de la película Flor de laburo Conclusión 56 28
Referencias [Jacobson/Griss/Jonsson] Ivar Jacobson, Martin Griss, Patrik Jonsson Software Reuse: Architecture, Process and Organization for Business Success Addison Wesley (1997) [Britton 2000] Chris Britton IT Architectures & Middleware: Strategies for Building Large, Integrated Systems Addison Wesley (2000) [McLaughlin 2002] Brett McLaughlin Building Java Enterprise Applications, Vol. 1: Architecture O'Reilly (2002) [Sewell/Sewell 2001] Marc T. Sewell, Laura M. Sewell The Software Architect's Profession: An Introduction Prentice Hall (2001) 57 29