Sobre la Práctica en la Construcción de Arquitecturas de Software Roberto Pardo Silva, Ph.D. Consultor ropardo@cable.net.co

Objetivo NO Hablar sobre cómo otros describen qué es arquitectura y cómo se debe hacer una arquitectura!!!! SI Compartir experiencias sobre cómo en la práctica he enfrentado la construcción de arquitecturas complejas de software

Temas Premisas y Metodologías Algunas Dimensiones 1 Premisas y Metodologías Algunas Dimensiones 2 Puntos aún no resueltos 3 4 Retos Futuros

Temas Premisas y Metodologías Algunas Dimensiones 1 Premisas y Metodologías Algunas Dimensiones 2 Puntos aún no resueltos 3 4 Retos Futuros

Casos Reales SIIF (Minhacienda, Colombia; BM) US$4MM-US$7MM Aprox, 11 Sistemas, 1150 Casos de Uso Plataforma .NET 2.0 PASEII (CGR Colombia; BID) US$5MM, 14 Sistemas, 1200 Casos de Uso J2EE BEA 8.1-Oracle SIGMA (Minhacienda Bolivia; BM) US$3MM, 8 Sistemas, Specs con Metodologia Propia Oracle Designer Otros (Portales, SIRS Honduras) Menos de US$500M, Diferentes tipos de Metodologías

Premisas Calidad de las Specs afecta Calidad de la Arquitectura “Completitud”, Claridad, Calidad de las Especificaciones CU ≠> “buenos” CU Flexibilidad, Rendimiento, Confiabilidad, Integración, Administración, etc. Otros Requerimientos Modelaje de las Especificaciones CU no capturan todo, v.g., Batch, algoritmos No muy formales en los req No funcionales MEF

Ejemplos de Especificaciones Ejemplos CU CU muy generales CU detallados CU muy general Ejemplo Funcionalidad de un Portal Sin CU, sin formalidad Ejemplo buenos CU: SIIF

Metodologías (Cuáles?) RUP es la más popular Artefacto de Arquitectura no es muy explícito Modelo de Análisis y Modelo de Diseño No dice cómo hacer una Arquitectura sino qué se incluye en las Vistas una vez se haya hecho No dice cómo pasar de CU a Arquitectura No maneja explícitamente Servicios!!!!! No dice cómo explotar las Plataformas

Etapas Claves Identificación de los Requerimientos Funcionales y No Funcionales de Arquitectura Identificación de los Servicios Transversales de Negocio Identificación de los Servicios Específicos de Negocio Identificación de los Servicios de Presentación Identificación de los Servicios de Persistencia Identificación de los Servicios Transversales No Funcionales Identificación de los Servicios Tecnológicos Orientada a Servicios!!!! Explicar las italicas

Consideraciones para Construir una Arquitectura de Negocio Existen Patrones de Negocio Patrones en Negocios de Venta al Detal, en Servicios Existen Patrones de Arquitectura pero no cubren muchos casos Comercio Electrónico: Carro de Compras + Pipeline Existe la “Metáfora del Negocio” para UI Workflow Tx vs Process oriented Pipeline Cómo se debe reflejar el negocio en una arquitectura de software?????

Temas Premisas y Metodologías Algunas Dimensiones 1 Premisas y Metodologías Algunas Dimensiones 2 Puntos aún no resueltos 3 4 Retos Futuros

Dimensiones de Análisis Presentación Reglas de Negocio Capa de Datos Seguridad Integración Flexibilidad Rendimiento Confiabilidad etc.

Matriz de Requerimientos de Arquitectura CU en las filas, Dimensiones en las columnas Defina Requerimientos Ejemplo SIIF

Dimensión de Arquitectura de Presentación Define cómo es la interacción (paradigma de comunicación hombre-máquina) del sistema con los diferentes usuarios del sistema. Decisiones de Arquitectura Metáfora de UI Modelo de Visualización Modelo de Navegación Modelo de Manejo de Estado de UI Manejo de Manejo de Multimedia Cómo se especifica la Presentación? PINTELA!!!!

Dimensión de Arquitectura de Reglas de Negocio Define cuáles son, y cómo se representan y agrupan las reglas de negocio dentro del sistema. Cómo y con qué frecuencia cambian? Decisiones de Arquitectura Modelo de RN alambrado Modelo de RN declarativo Modelo de RN en motores de BD Modelo de Motor de RN Cómo se especifican las RN? BD

Dimensión de Arquitectura de Acceso a Datos Los requerimientos que definen la naturaleza de los diferentes tipos de repositorios de información que tendrá el sistema, así como los medios para interactuar con éstos. Decisiones de Arquitectura en Datos Modelo de Tipos de Datos Modelo de Persistencia (en OO es el mapping) Modelo de Transacciones Modelo de Concurrencia Modelo de Acceso a Datos Cómo se especifican? E-R?

Dimensión de Arquitectura de Seguridad Los requerimientos del sistema en materia de seguridad: autenticación, autorización, auditoria, manejo de perfiles, seguridad de comunicaciones y datos. Decisiones de Arquitectura Modelo de Autenticación Tipos de Llaves, Repositorios, Integración con SSO, Portales Modelo de Autorización Modelo de Permisos: Roles, Grupos, Perfiles, Localización, Tiempo Relación con cada Capa y Servicio Asociación con elementos de Arquitectura Código, Transacciones Modelo de Auditoría No es claro cómo hacer especificaciones de Seguridad

Dimensión de Arquitectura de Rendimiento Requerimientos sobre consumo de recursos, tiempos de respuesta, productividad (“throughput”) esperados para las operaciones del sistema. No es claro cómo hacer especificaciones de Rendimiento Decisiones de Arquitectura Modelo de Cliente Smart, Rich, etc. Modelo de Asincronismo: Ajax, etc. Modelo de Caching Modelo de Pooling Objetos, Conexiones, etc.

Dimensión de Confiabilidad Requerimientos sobre las exigencias de confiabilidad de datos y operaciones. Incluye aquellos requerimientos de disponibilidad y tolerancia a fallas. Decisiones de Arquitectura en Confiabilidad Modelo de Fallas Modelo de Redundancias Modelo de Atomicidad en Tx Modelo de Recuperación No es claro cómo hacer especificaciones de Confiabilidad

Dimensión de Integración Requerimientos que indican los diferentes tipos de esquemas de integración del sistema con otros sistemas (internos y externos). Se debe indicar la naturaleza de la integración (datos, operaciones o ambos), el medio o protocolo de comunicación, sincronía de ésta, frecuencia, volúmenes de información transmitida y nivel de seguridad. No es tan claro cómo hacer especificaciones de Integración. CU Hay CU de sólo integración, Hay CU que “llaman” a otros CU Se pueden hacer Matrices de Integración Decisiones de Arquitectura Modelo de Integración Mensajes, RPC, File Sharing Modelo de Interacción RR, Stateless

Dimensión de Arquitectura de Flexibilidad Requerimientos que indican el nivel de extensibilidad, parametrización y capacidad de evolucionar que se espera del sistema. Decisiones de Arquitectura en Flexibilidad Modelos de “Extensibilidad” Interfases OO, Patrones de Diseño No es claro cómo hacer Especificaciones de Flexibilidad

Ejemplos de Arquitecturas (SIIF) Identificación de Servicios SOA Transaccionalidad Asincronismo Gestión de Procesos

Puntos Críticos aún sin buenas soluciones Cómo Evaluar lo que se hace? Lenguaje de Descripción de Arquitectura Métricas de Arquitectura Trazabilidad con otras Actividades del Ciclo de Desarrollo

Temas Premisas y Metodologías Algunas Dimensiones 1 Premisas y Metodologías Algunas Dimensiones 2 Puntos aún no resueltos 3 4 Retos Futuros

Futuros (próximos) que afectan Arquitectura Nuevas Herramientas y Frameworks Nuevos Modelos de Programación Nuevas Plataformas Nuevos modelos de Conectividad Avances en HW Nuevos Modelos de Aplicaciones

Nuevas Herramientas Librerías y Frameworks Lenguajes Visuales DSL (Domain Specific Languages) VS 2005 TEAM SYSTEM ARCHITECTS

Nuevos Modelos de Programación No todo es OO Programación Funcional = Evaluación de Expresiones Funciones, Composición, Tipos Programación Lógica = Deducción Search Engines LINQ Ver lo de LINQ, videos, papers, instalación y anotar su impacto en ARQUITECTURA DSL: ARC 411 de TECHED 2005

Nuevas Plataformas Indigo Avalon .NET 2.0, Visual Studio 2005 Team Architech Video Indigo Avalon

Nuevos Modelos de Aplicaciones Comerciales Aplicaciones son Plataformas, no se escriben sobre Plataformas Su propio modelo de objetos UI, Negocio, Persistencia, Seguridad SU propio modelo de programación Lenguaje DSL, multiparadigma SU propio modelo de extensibilidad Integración Su propio runtime

Conclusión Arquitectura requiere mucha creatividad y experiencia No hay recetas Qué tanto hacer en Arquitectura? Si el problema es “chiquito” Arquitectura = Diseño Si el problema es muy grande Arquitectura tiende a ser muy general