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

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

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/

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.

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

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

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)

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)

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

Elementos relacionados con la arquitectura Por 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

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

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

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

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

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

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

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 Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #n Iter. #n+1 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

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

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

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

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)

Árbol de calidad (ATAM) 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

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

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

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

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

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

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

Correspondencia ADL & UML - Ejemplo en C2

Correspondencia ADL & UML - Ejemplo en C2 (2)

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

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 (¿?)

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)

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

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

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

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

UML2.0: Facilidad para composición estructural (2) 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 composite port port Detector pCtrl Maintenance InsertCoin CoinControl, Counter

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

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

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

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

Vista general de MDA

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)

Arquitectura de UML de cuatro niveles (OMG)

Arquitectura de UML de cuatro niveles (OMG): Ejemplo

Estructura de extensión de los lenguajes

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

El proceso de transformación

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

El proceso MDA: 2. Transformación de CIM a PIM Modelo detallado con Pre y Post en (OCL) y con semantica de comportamiento (Action Semantic) El modelo representa funcionalidad y comportamiento sin detalles de la tecnología, Modelo Independiente De Plataforma

El proceso MDA: 3. Probar PIM CIM Modelo Independiente De Plataforma Entorno de Animación del Modelo

El proceso MDA: 4. Definir reglas de transformación CIM Entorno de Animación del Modelo Modelo Independiente De Plataforma Reglas de Transformación PIM - PSM

El proceso MDA: 5. Marcar el modelo CIM Entorno de Animación del Modelo Modelo Independiente De Plataforma + Marcas para transformación Reglas de Transformación PIM - PSM

El proceso MDA: 6. Generar PSM (Platform-Specific Model) CIM Entorno de Animación del Modelo Platform- Independent Model + Marcas para transformación CORBA Model Mapear PIM a tecnología de middleware específica

El proceso MDA: 6. Mapear a múltiples tecnologías Map a PIM to Many Middleware Technologies via OMG Standard Mappings MDA tool applies an standard mapping to generate Platform-Specific Model (PSM) from the PIM. Code is partially automatic, partially hand-written. Platform- Independent Model Other Model XML/SOAP Model Java/EJB Model CORBA Model

El proceso MDA: 7. Generación de código Map PSM to application interfaces, code, GUI descriptors, SQL queries, etc. Platform- Independent Model Las herramientas MDA generar la mayor parte del código en la tecnología específica Other Model XML/SOAP Model Java/EJB Model CORBA Model CORBA Java/EJB XML/SOAP Other

El proceso MDA: 8. Integrar aplicaciones legado y COTS Reverse-engineer existing application into a model and redeploy. Platform- Independent Model Las herramientas MDA para ingeniería reversa apoyan el proceso de integración de aplicaciones legado Other Model Legacy App COTS App Other

El proceso MDA: 9. Generación de adaptadores (bridges) Platform- Independent Model MDA Tools combine application and platform knowledge to generate bridges CORBA Model XML/SOAP Model CORBA System Interop Bridge XML/SOAP System

Herramientas MDA

Herramientas MDA (Libres) UMT - (UML Model Transformation Tool Model Transformation Framework (MTF) open Architectureware Eclipse plugin iQgen 2.0 Metadata Transformer/Generator (MTG) Motion Modeling The ATL Engine MTL Engine ModFact Generative Model Transformer (GMT) (Surge OMELET) Kent Modelling Framework (KMF) AndroMDA OpenMDX JunoMDA

Herramientas MDA (Comerciales) ArcStyler MCC (Model Component Compiler) Codagen Architect OptimalJ Xactium XMF Mosiac SosyInc Modeler and Transformation Engine Model-in-Action

Clasificación de soluciones existentes De modelo a código Visitor based: mecanismo para recorrer la representación interna del modelo y generar el código (Ej. Jamda) Template based: (Ej: b+m Generator Framework, JET, FUUT-je, Codagen Architect, AndroMDA, ArcStyler, OptimalJ and XDE) De modelo a modelo direct-manipulation: Generalmente implementadas como framework OO como una estructura para organizar las transformaciones (Ej: jamda, jmi) Relational:Aproximaciones declarativas basadas en relaciones matemáticas utilizando lenguajes lógicos (ej: F-Logic) graph-transformation-based: Se utilizan grafos para expresar en un único formalismo los diferentes modelos (Ej:VIATRA, ATOM, GreAT, UMLX, and BOTL) structure-driven: Realiza la transformación en dos fases: en la primera fase se crea la estructura jerárquica del modelo destino y en la segunda fase se actualizan las propiedades y referencias en el modelo destino (ej: OptimaJ, IOPT). Practica para transformación a plataformas como J2EE hybrid approaches. Combinan diferentes técnicas de las categorías anteriores (Ej: TRL combina aproximacion declarativa e imperativa; ATL puede ser completamente declarativa, híbidra o totalmente imperativa) transformación utilizando XSLT. Dificultades: baja escalabilidad, dificultad para escribir las reglas de transformación Jamda, XDE, OptimalJ permite ambas transformaciones

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

Conclusiones La arquitectura como estrategia para enfrentar la complejidad de los sistemas actuales Las actividades alrededor de la arquitectura deben integrarse al proceso de desarrollo UML2.0 provee facilidades para definición de la arquitectura MDA como enfoque de desarrollo donde los modelos son los constructores de primera clase

¿Preguntas?