Sobre la Práctica en la Construcción de Arquitecturas de Software

Presentación del tema: "Sobre la Práctica en la Construcción de Arquitecturas de Software"— Transcripción de la presentación:

1 Sobre la Práctica en la Construcción de Arquitecturas de Software
Roberto Pardo Silva, Ph.D. Consultor

2 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

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

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

5 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

6 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

7 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

8 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

9 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

10 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?????

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

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

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

14 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!!!!

15 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

16 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?

17 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

18 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.

19 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

20 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

21 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

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

23

24 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

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

26 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

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

28 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

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

30 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

31 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