Architect Academy Webcast #4: Diseñando la arquitectura

1. Architect AcademyWebcast #4:Diseñando la arquitectura Billy Reynoso Universidad de Buenos Aires billyr@microsoft.com.ar

2. Roadmap • Webcast #1: ¿Qué es la Arquitectura de Software? • Webcast #2: Drilldown en Estilos de Arquitectura de Software • Webcast #3: Arquitectura para distribución y agregación: Services Oriented Architecture (SOA) • Webcast #4: Diseñando la arquitectura

3. Objetivos • Propósito de la serie de Webcasts: • Comprender la teoría y orientar la práctica de la Arquitectura de Software • Vincular concepciones de la academia y la industria • Relacionar los principios teóricos con herramientas y ambientes Microsoft • Propósito de la sesión de hoy: • Conocer conceptos y herramientas de diseño arquitectónico de alto nivel, pero con impacto sobre código • Disipar algunos malentendidos comunes • Proporcionar referencias para profundizar en la práctica específica del diseño arquitectónico

4. Diseñando la Arquitectura • Temario • Problemas y perspectivas del diseño arquitectónico • Concepciones de diseño de la industria y la academia • Vista rápida de los Lenguajes de Descripción de Arquitectura (ADL) • ACME/Armani, Wright, CHAM, ADLs basados en C2 – xADL, Jacal • La Arquitectura no es modelado en UML • Los límites de UML (2) como lenguaje de modelado arquitectónico • Perspectiva académica – No es el punto de vista de Microsoft • Arquitectura de software y MDA • Estado de arte del diseño arquitectónico: Sacando provecho de herramientas, patrones y prácticas – Factorías y DSLs • Estudios de casos • Visión del futuro – Integrando arquitectura, diseño y desarrollo en Visual Studio 2005 (Team System)

5. 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 de Arquitectura • 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

6. ADLs • Herramientas de modelado que soportan desarrollos basados en arquitecturas • Estructura de alto nivel, no detalle de implementación • Poco consenso respecto a definición de ADL, aspectos a considerar y adecuación de ADLs a estilos • Poca distinción entre ADL, especificación formal, interconexión de módulos (MIL), herramientas de modelado y hasta lenguajes de programación

7. Condiciones de la descripción arquitectónica • Componentes, con aserción de propiedades, interfaces e implementaciones • Conectores, con aserción de protocolos, interfaces e implementaciones • Configuraciones o sistemas, abstracción y encapsulamiento • Propiedades no funcionales • Restricciones • Estilos • Evolución • Herramientas de verificación

9. Otras herramientas • 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) • Lenguajes específicos de dominio (DSLs)

10. ADLs

11. Acme / Armani • Lenguaje de intercambio de arquitectura • 1995, Carnegie Mellon • Lenguaje Acme • Acme Tool Developer’s Library (AcmeLib) • 4 tipos de arquitectura • Estructura, propiedades (comportamiento), restricciones, tipos y estilos • Estructura: componentes, conectores, sistemas, puertos, roles, representaciones y rep-mapas

12. Acme/Armani • Semántica sólo como comentario • No genera código • Maneja estilos (familia) • Varias herramientas en ambiente Windows: • AcmeStudio • Armani con front-end Visio • ISI: front-end Powerpoint • ADML: lenguaje de markup de arquitectura, derivado de Acme (estándar) • Armani: ADL. Declarativo

13. Acme/Armani

18. ADML • Open Group, 2000 • ADML: XML con DTD • xADL (“Zaydal”,UCI): Schemas para estilos (Aplicación de xArch) • xArch (UCI/Carnegie Mellon): lenguaje basado en XML para descripción de arquitecturas – Placeholder para implementaciones variables

19. Aesop (inactivo?)

20. C2 SADL, C2SADEL • C2 SADL (Simulation Architecture Description Language) • ADL que permite describir arquitecturas en estilo C2 • C2SADEL – Variante. Incluye DRADEL (Development of Robust Architectures using a Description and Evolution Language) • xArch, xADL: Inicialmente ligados a C2

21. C2 SADL, C2SADEL • SADL • Módulos declarativos e imperativos • 1) IDN Interface Description Notation • 2) ADN Architecture Description Notation • 3) ACN Architecture Construction Notation • Windows: • DRADEL (Int. Para C2SADEL) • SAAGE (requiere Rose o Dradel) • ArchStudio – Argo (discontinuado)

22. C2

23. C2

24. CHAM • Chemical Abstract Machine • Técnica de especificación basada en álgebra de procesos • Moléculas (componentes básicos) • Soluciones de moléculas (multiconjuntos que definen estados) • Reglas de transformación (cambios de estado) – No determinismo si hay + de una regla para una molécula o solución

25. CHAM • Ejemplo de compilador Lisp

28. Jacal (1/2) http://www.microsoft.com/spanish/msdn/arquitectura

29. Jacal (2/2)

35. MetaH / AADL

36. Wright (1/2) • Herramienta de formalización de conexiones arquitectónicas, CMU (parte de proyecto ABLE) • ABLE: herramienta de diseño (Aesop), especificación formal (Wright) • Integración de metodología formal con descripciones arquitectónicas • Aplica procesos formales (álgebra de proceso y refinamiento de proceso) a verificación automatizada de propiedades de arquitectura

37. Wright (2/2) • Declara conjunto de tipos de componentes y conectores y conjunto de restricciones • Modelo semántico basado en CSP (Communicating Sequential Process de Hoare) • Verificación mediante verificador comercial FDR • Restricciones: predicado que debe ser satisfecho por cualquier configuración que se declare miembro del estilo • Notación de restricciones: cálculo de predicados de primer orden • Sub-estilos: heredan de estilos • No posee interfaz gráfica nativa • No genera código ejecutable

39. Modelos formales • Darwin: cálculo Pi • Wright: 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

40. Conclusiones respecto de ADLs • No hay ninguno que sea dominante en la academia o la industria • Deben reformularse para vincularse con XML y UML 2 • Muchos de ellos sin actividad en los últimos años • Algunos son específicos de industrias pesadas • Poco énfasis en desarrollo de ADLs en SEI/CMU • Momento de transición • Extensiones arquitectónicas de UML 2, MDA, DSLs • Adopción de modelos abstractos y factorías en la industria • Modelado comienza a vincularse a herramientas de desarrollo • No se quiere repetir la experiencia de los CASE

41. UML y Arquitectura

42. UML Limitaciones arquitectónicas • Hofmeister, 1999: • La notación gráfica de UML es deficiente para mostrar correspondencias entre elementos en diferentes vistas. Esto se logra mejor con una tabla. • Protocolos: no se puede mostrar comunicación peer-to-peer en UML [1]. Hay que utilizar una notación externa, como ROOM (Real-time Object-Oriented Modeling). • Puertos en componentes. La notación es confusa y requiere (p. ej.) anidamiento. Una notación “lollipop” sería preferible. • Aspectos dinámicos de la estructura. Diagramas de secuencia y de estado describen la conducta dinámica, pero no soportan configuración dinámica (ni siquiera para estilos basados en objeto).

43. UMLLimitaciones arquitectónicas • Abdurazik, 2000 • Los diagramas de componentes de UML no representan la descomposición lógica de un sistema en subsistemas reutilizables y combinables • UML no proporciona concepto de conectores como objetos de primera clase • Estos serían un híbrido de una clase de asociación y una dependencia entre una clase y una interface de otra clase. • UML se puede extender para modelar cualquier cosa, pero se pierde soporte de herramientas e intercambiabilidad

44. UMLLimitaciones arquitectónicas • Cuestionamientos genéricos (reconocidos por OMG) • Tamaño excesivo (al mismo tiempo demasiado y demasiado poco) • Semántica ambigua • “Puede parecer visualmente clara, pero las intuiciones subyacentes son confusas” (Garlan) • La interpretación de los tipos de UML difiere entre stakeholders con distinta formación e intereses (Perrouin 2002) • La semántica no está formalmente definida, sino librada a la imaginación del usuario (Klaus-Dieter Schewe) • Relaciones ambiguas y oscuras entre vistas, no susceptibles de tratamiento formal • Extensibilidad a costa del soporte de herramientas y de una especificación estándar • Adaptabilidad (customización) limitada

45. UMLLimitaciones arquitectónicas • Cuestionamientos genéricos (cont.) • Soporte insatisfactorio para desarrollo basado en componentes • Posibilidad de incurrir en el “síndrome de la segunda versión” (Brooks) • Poca orientación semántica para arquitectos (p.ej. cuándo usar un diagrama) • “In-analisibilidad” (Garlan) • “Aunque se lo pueda representar, y luzca bien, no hay nada que se pueda hacer con él, excepto usarlo como documentación” • Falta de soporte para estilos • Como profiles el manejo es pesado; como packages se soporta agregación, pero no restricciones (Garlan)

46. UMLLimitaciones arquitectónicas • Guéhéneuc-Amiot-Douence-Cointe (2002) • UML y lenguajes OO tienen conceptos de clase y herencia. • Pero hay nociones que existen en UML y no en lenguajes: estereotipo, relaciones de clases binarias (asociación, agregación, composición)* • La definición de relaciones binarias en UML está en lenguaje natural y es ambigua; no hay lineamientos sobre su implementación. * Ver diagramas en Enterprise Architect, eventualmente

47. UMLLimitaciones arquitectónicas • Guéhéneuc-Amiot-Douence-Cointe (2002, cont.) • Las herramientas (Rational Rose, Together, Borland Jbuilder, ArgoUML) no tienen definiciones claras de relaciones binarias. Las distinguen gráficamente, pero el código generado es el mismo. • Clases Asociadas: ocurren juntas (Factura – Vendedor); 2 elementos tienen una relación- Línea continua • Composición: una clase es parte de otra (Item-Factura) – Línea con rombo lleno en clase mayor – Forma fuerte de agregación • Agregación: Sin herencia (p.ej. Orden de compra tiene un cliente) – Rombo sin relleno. Una clase es usada por otra.

48. UMLLimitaciones arquitectónicas • Este diagrama de clases muestra tres clases, una relación de herencia y una de agregación • En Java esto resultaría en • public class A { • ... • } • public class B extends A { • ... • } • public class C { • ... • } • ¿Cómo se implementa la relación de agregación entre B y C? ¿Como campo? ¿Como colección? ¿Como par de getter y setter? ¿Como par de métodosadd()-remove()?

49. UMLLimitaciones arquitectónicas • En Rational Rose 2001.03.00 este diagrama de dos clases con una relación de agregación genera el mismo código Java que para relaciones de asociación y composición, aunque sus semánticas y notaciones sean distintas • Cuando se reemplaza el array por una colección instancia de java.util.vector p.ej. (como se hace habitualmente) y se hace ingeniería reversa del código para generar UML, desaparece la agregación, y aparece una asociación inconsistente con el diagrama original

50. UMLLimitaciones arquitectónicas • Martin Glinz - Deficiencias de UML como lenguaje de especificación de requisitos • UML no puede modelar interacciones iniciadas por el sistema (y no por un actor) • UML prohibe explícitamente establecer relaciones entre actores, perdiendo capacidad para expresar contextos complejos • UML no permite expresar estructuras ni jerarquías entre casos de uso • UML no permite relaciones entre casos de uso (p. ej. un caso que requiera la finalización de otro)