Especificación y Modelado de Arquitecturas Software

1. Raquel Anaya ranaya@eafit.edu.co Especificación y Modelado de Arquitecturas Software

2. Agenda Conferencia • Motivación • El proceso de desarrollo basado en la arquitectura • Evaluación de la arquitectura • Lenguajes para representación de la arquitectura • MDA una propuesta de arquitectura alrededor de los modelos • Conclusiones y Preguntas

3. Orígenes • “La arquitectura descansa en tres principios: la Belleza (Venustas), la Firmeza (Firmitas) y la Utilidad (Utilitas)” • (Vitruvio, siglo I a de C) Templo de Artemisa en Efeso Siglo IV a de C. 127 columnas de 20 metros de altura El coloso de rodas 277 a de C. 32 metros de altura Placas de bronce sobre armazón de hierro Fuente: http://sietemaravillas.tripod.com/

4. Orígenes (2) • “Es arquitecto aquel que con método y procedimiento seguro y perfecto sepa proyectar racionalmente y realizar en la práctica obras que se acomoden perfectamente a las más importantes necesidades humanas.“ • León Batista Alberti( 1485) Las pirámides de Egipto. Año 2750 a de C. 146.59 m de altura, 230 m de ancho Alineadas hacia el norte con una inclinación de 51 grados El faro de Alejandría. Año 280 a de C. Altura 120 metros. Cima equipada con espejos metálicos que reflejaban la luz del sol; y por las noches, a falta de luz, se enciende una hoguera.

5. Orígenes (3) • “Una arquitectura debe incorporar la unidad difícil de la inclusión en vez de la unidad fácil de la exclusión “ • Robert Venturi(1966) Evolución de la Ingeniería Civil - Imitación de esfuerzos previos - Aprendiendo de las fallas - Integración de otras fuerzas - Experimentación Fuente: Rational Rose

6. Qué es una arquitectura software? • La arquitectura del software define el sistema en términos de sus componentes computacionales y de las relaciones entre ellos (Shaw & Garlan, 1996) • “Estructura o estructuras del sistema que comprende componentes de software, propiedades visibles de esos componentes y las relaciones entre ellos.”

7. Arquitectura: Pensar primero en lo importante Diseño de alto nivel versus diseño detallado (David Budgen) Esqueleto versus Carne y Músculos (Rational Unify Process)

8. Arquitectura vs. complejidad • En la medida que la complejidad de los sistemas crece, los algoritmos y las estructuras de datos dejan de convertirse en el mayor problema. • El diseño y especificación de la estructura general del sistema emerge como un nuevo tipo de problema: el diseño a nivel de arquitectura. • En aplicaciones OO las clases representan unidades de granularidad muy fina; en sistemas grandes se requiere hablar de unidades que represente una funcionalidad mayor (módulos / subsistemas / componentes de negocio)

9. Arquitectura vs. complejidad (2) Fuente: Architecture as a Business Competency. Bredemeyer Consulting

10. Elementos relacionados con la arquitectura Por qué? Qué? Características Del Sistema Cualidades de la Arquitectura Satisface Arquitectura Requerimientos S/W Restringe Representación de la arquitectura Atributos de Calidad del sistema Tecnología Produce Defines Para qué? Quién? Analiza Arquitecto Procesos Habilidades Define roles Organización Stakeholders Fuente: Rational Software

11. Influencias hacia y desde la arquitectura El ciclo ABC (Arquitecture Business Cycle) Fuente: Linda Northrop. Cargnegie Melon University

12. usuario final soporte aplicativo líder de mercadeo cliente Influencias de los participantes sobre el arquitecto Funcionalidad Rendimiento Seguridad usabilidad gerente del proyecto Bajo costo Rendimiento del equipo modificabilidad arquitecto Corto tiempo en mercado Bajo costo; ventajas con productos similares Bajo costo y tiempo de entrega, que no cambie muy a menudo

13. Agenda Conferencia • Motivación • El proceso de desarrollo basado en la arquitectura • Evaluación de la arquitectura • Lenguajes para representación de la arquitectura • MDA una propuesta de arquitectura alrededor de los modelos • Conclusiones y Preguntas

14. Pasos generales de un proceso de desarrollo basado en la arquitectura • 1. Evaluar la necesidad empresarial del sistema • Asegurar que la organización requiere el sistema • Cuánto costará el producto? • Cuál es el mercado objetivo? • Cuál es el tiempo de puesta en el mercado? • Qué interacciones se requieren con otros sistemas? • 2. Entender los requerimientos • Técnicas de elicitación de requisitos (casos de uso, escenarios) • Para sistemas de seguridad crítica utilizar aproximaciones rigurosas como máquinas de estado finito o lenguajes formales • Cuáles son las características particulares del sistema con respecto a otros sistemas (por ejemplo líneas de producto)?

15. Pasos generales de un proceso basado en la arquitectura (2) • 3. Crear o seleccionar la Arquitectura • Cuáles son los estilos de arquitectura adecuados? • Layer, MVC, Blackboard, Tuberias y Flitros, etc. • Qué papel juegan las aplicaciones legado? • Cuáles son las tácticas de arquitectura para cumplir un atributo de calidad? • 4. Representar y comunicar la arquitectura • Uso de modelos y de documentos de definición de arquitecturas • Sesiones para comunicación y discusión de la arquitectura con todos los stakeholders • 5. Analizar o evaluar la arquitectura • Definir varias alternativas de arquitectura • Utilizar métodos de evaluación de arquitectura

16. Pasos generales de un proceso basado en la arquitectura (3) • 6. Implementar el sistema basado en la arquitectura • Implementar las interfaces definidas en la arquitectura • Tener un ambiente o infraestructura que asista activamente a los desarrolladores en la creación y mantenimiento de la arquitectura • 7. Asegurar que la implementación corresponde a la arquitectura • Establecer un proceso de monitoreo permanente para asegurar que la arquitectura actual y su representación se mantienen consistentes durante su operación y evolución

17. La arquitectura y la propuesta del Proceso Unificado Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Iter.#n+1 Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#n Enfatiza la importancia de: • Especificación precisa de requisitos no funcionales • Pruebas de concepto de la arquitectura • Definición de la línea base de la arquitectura • Procesos formales de análisis y evaluación de la arquitectura

18. Impactos del desarrollo basado en la arquitectura En la ingeniería • Importancia de modelos de alto nivel que luego se refinan • Desarrollo basado en interfaces antes que clases • Uso de patrones y tácticas de arquitectura Desarrollo Basado en la Arquitectura En la gestión del proyecto En la calidad del producto • Estimar esfuerzo de construcción • Plan de construcción de los CU según su • impacto en la arquitectura • Nuevos esquemas de negociación del proyecto • Nuevos esquemas de interacción cliente/proveedor • La arquitectura como elemento para evaluar • riesgos • Medición de la calidad “sobre • planos” • Adopción de frameworks de • atributos de calidad

19. Agenda Conferencia • Motivación • El proceso de desarrollo basado en la arquitectura • Evaluación de la arquitectura • Lenguajes para representación de la arquitectura • MDA una propuesta de arquitectura alrededor de los modelos • Conclusiones y Preguntas

20. Escenarios de atributos de calidad • Utilizados para: • Precisar los atributos de calidad en la fase de definición de requisitos • Verificar el cumplimiento del contrato en las fases de diseño e implantación

21. Técnicas de apoyo al análisis y evaluación de arquitecturas propuestas por el SEI • Para obtener los casos de negocio y entender los requerimientos • Quality Attribute Workshop (QAW) • Para crear o seleccionar la arquitectura • Attribute Driven Desing (ADD) • Para documentar y comunicar la arquitectura • View and Beyond Approach • Para analizar y evaluar la arquitectura • Architecture Tradeoff Analysis Method (ATAM) • Cost Benefit Analysis Method (CBAM) • Software Architecture Analysis Method (SAAM)

22. Utilizado para articular las metas esperadas del sistema con respecto a los atributos de calidad Las hojas del árbol presentan los escenarios considerados relevantes a la arquitectura Se asignan peso a cada rama del árbol según su importancia y dificultad de implementación Árbol de calidad(ATAM)

23. Agenda Conferencia • Motivación • El proceso de desarrollo basado en la arquitectura • Evaluación de la arquitectura • Lenguajes para representación de la arquitectura • MDA una propuesta de arquitectura alrededor de los modelos • Conclusiones y Preguntas

24. Qué es un ADL (Architecture Definition Language)? • “Un ADL enfoca en la descripción de la estructura de la aplicación a alto nivel, en lugar de la descripción de la implementación de cualquier módulo específico.” • ADL es un lenguaje que provee elementos para modelar la arquitectura conceptual de un sistema software, distinguiéndola de la implementación del sistema (Medvidovic&Taylor) • Constructores básicos de un ADL: Componentes, Conectores, Configuraciones y Restricciones (Tracz, 1993). • El problema: Los lenguajes formales son difíciles de entender y manejar en aplicaciones industriales • Reto: Convertir a UML en un lenguaje suficientemente preciso para especificar una arquitectura

25. Relación de ADL´s con otras notaciones y herramientas

26. Principales lenguajes ADL • ACME: Architectural interchange, predominantly at the structural level • Aesop: Specification of architectures in specific styles • C2: Architectures of highly-distributed, evolvable, and dynamic systems • Darwin: Architectures of highly-distributed systems whose dynamism is guided by strict formal underpinnings • MetaH: Architectures in the guidance, navigation, and control (GN&C) domain • Rapide: Modelling and simulation of the dynamic behaviour described by an architecture • SADL: Formal refinement of architectures across levels of detail • UniCon: Glue code generation for interconnecting existing components using common interaction protocols • Weaves: Data-flow architectures, characterized by high volume of data and real-time requirements on its processing • Wright: Modelling and analysis (specifically, deadlock analysis) of the dynamic behaviour of concurrent systemsx • XADL: Extensible XML-based ADL based on xArch

27. Editor gráfico para diseño de arquitecturas Diseño de estilos o familias de arquitectura Implementado como plug-in de Eclipse Ejemplo de un ADL: Acme Studio

28. Alternativas de integración de UML con ADL´s • Alternativa 1. Buscar correspondencia entre ADL´s existentes y UML ADL : Para el diseño de alto nivel UML : Para el diseño detallado

29. Correspondencia ADL & UML - Ejemplo en C2

30. Correspondencia ADL & UML - Ejemplo en C2 (2)

31. Alternativas de utilización de UML como ADL Alternativa 2. Adecuar UML por medio de estereotipos • Esta estrategia ha sido aplicada en lenguajes como C2 , Wright y Rapide • Ventajas: • Representa de manera explícita las restricciones arquitecturales a través de OCL • Entendible por los desarrolladores y soportado por herramientas CASE • Las tareas de ingeniería inversa a través de estereotipos podrían simplificarse • Desventajas: • Dificultad para establecer los límites entre el diseño de la arquitectura y el diseño detallado • Incapacidad de las herramientas CASE para forzar el cumplimiento de restricciones escritas en OCL • Dificultad para representar en UML la semántica particular de algunos lenguajes de ADL

32. Alternativas de utilización de UML como ADL Alternativa 3. Extender UML • Extender el metamodelo de UML para soportar directamente los constructores de arquitectura • Incorporar formalmente en UML nuevas capacidades de modelado • Se puede simplificar las tareas de generar la arquitectura a partir del diseño • Reto: Estandarizar el lenguaje sin incrementar demasiado la complejidad de la especificación (¿?)

33. Características de las extensiones de UML 2.0 • Mayor riqueza semántica en la definición del comportamiento del sistema • Facilidad para definir composición de elementos • Composición estructural • Composición del comportamiento • Conectores y puertos como constructores asociados a los clasificadores (clases y componentes)

34. Variaciones para expresar Paralelismo y alternativas Iteraciones y opcionalidad Excepciones Este cambio reduce el número de diagramas requeridos para expresar la funcionalidad UML2.0: Extensiones en la definición del comportamiento en diagrama de secuencias sd ValidateCoin :User :VendingMachine Insert(coin) alt Display(price) else Operador De la interacción RejectCoin()

35. La línea de vida de un objeto puede ser expandida con el propósito de proveer diferentes niveles de abstracción UML2.0: Facilidad para especificar el comportamiento en diferentes niveles de detalle sd Decomposition :Detector create :Controller sd Overview Insert(coin) :User :VendingMachine ref Decomposition ValidateCoin() RejectCoin() Insert(coin) RejectCoin()

36. Evita duplicación de secuencias repetitivas Mayor consistencia con la definición de flujos obligatorios y opcionales declarados en el caso de uso UML2.0: Facilidad para factorizar comportamientos comunes / alternativos sd BuyScenario :User :VendingMachine ref ChooseProduct Display(price) ref ValidateCoin

37. La clase como una entidad stand-alone con interfaces requeridas y provistas UML2.0: Facilidad para composición estructural VendingMachine InsertCoin Interface Provista Display Interface Requerida

38. Una misma clase con diferentes comportamientos Cada comportamiento representa un “puerto” de acceso a la clase El puerto actua como un único punto de interacción de la clase UML2.0: Facilidad para composición estructural (2) composite port port pCtrl Maintenance Detector InsertCoin CoinControl, Counter

39. Permite descomposición jerárquica de la clase Los conectores son utilizados como asociaciones contextuales UML2.0: Facilidad para composición estructural (3) Class Part VendingMachine :Counter :Detector pCtrl Counter InsertCoin InsertCoin :Controller CoinControl Display Display Connector

40. End-user Functionality LogicalView Implementation View Programmers Software management Use Case View System integrators Process View Deployment View Performance Scalability Throughput System engineering System topology Delivery, installation Communication El modelo de arquitectura de UML: 4+1 vistas Fuente: Rational Software

41. Agenda Conferencia • Motivación • El proceso de desarrollo basado en la arquitectura • Evaluación de la arquitectura • Lenguajes para representación de la arquitectura • MDA una propuesta de arquitectura alrededor de los modelos • Conclusiones y Preguntas

42. La promesa de MDA (Model Driven Architecture) De desarrollo basado en código a desarrollo basado en modelos From: Automating Software Developmentwith UML 2.0, Cris Cobryn

43. Vista general de MDA

44. Quién lidera la iniciativa de MDA? • El grupo OMG (Object Management Group) • MDA: “The new OMG baby” • Nueva orientación de las actividades de la OMG • Más allá de las propuestas de middleware (CORBA) • Influenciado por la amplia aceptación de UML • Estándares que ha impulsado la OMG • Meta Object FacilityTM (MOF) • Unified Modeling LanguageTM (UML) • Common Warehouse MetamodelTM (CWM) • XML Metadata InterchangeTM (XMI)

45. Arquitectura de UML de cuatro niveles (OMG)

46. Arquitectura de UML de cuatro niveles (OMG): Ejemplo

47. Estructura de extensión de los lenguajes

48. El proceso de transformacion • La transformación es la generación automática de un modelo fuente en un modelo objetivo, de acuerdo a unas definiciones de transformación • Una definición de transformación esta conformada por un conjunto de reglas que describen como el modelo en el lenguaje fuente puede ser transformado en un modelo en el lenguaje destino • Una regla de transformación es una descripción de uno o más constructores en el lenguaje fuente que pueden ser transformados en uno o mas constructores en el lenguaje destino

49. El proceso de transformación

50. El proceso MDA: 1. Construcción del CIM Modelo Independiente de la Computación Modelo que representa la semántica del negocio