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 Supporting Workflows Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#n Iter.#n+1 Deployment Configuration Mgmt Requirements Elaboration Transition Inception Construction 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 Enfatiza la importancia de:
Impactos del desarrollo basado en la arquitectura Desarrollo Basado en la Arquitectura 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 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
En la ingeniería En la gestión del proyecto En la calidad del producto
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
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
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
Alternativa 2. Adecuar UML por medio de estereotipos
Alternativas de utilización de UML como ADL 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 (¿?) Alternativa 3. Extender UML
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 :VendingMachine :User Insert(coin) Display(price) RejectCoin() alt else Operador De la interacción
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 Overview :VendingMachine ref Decomposition Insert(coin) RejectCoin() :User sd Decomposition :Detector :Controller RejectCoin() create Insert(coin) ValidateCoin()
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 :VendingMachine :User Display(price) ref ChooseProduct ref ValidateCoin
UML2.0: Facilidad para composición estructural La clase como una entidad stand-alone con interfaces requeridas y provistas
VendingMachine Display InsertCoin Interface Requerida Interface Provista
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
Detector InsertCoin CoinControl, Counter Maintenance port composite port pCtrl
UML2.0: Facilidad para composición estructural (3) Permite descomposición jerárquica de la clase Los conectores son utilizados como asociaciones contextuales VendingMachine InsertCoin Display :Detector Connector Part Class :Counter :Controller InsertCoin pCtrl Counter CoinControl Display
El modelo de arquitectura de UML: 4+1 vistas (Gp:) Logical View (Gp:) End-user (Gp:) Functionality (Gp:) Implementation View (Gp:) Programmers Software management (Gp:) Process View (Gp:) Performance Scalability Throughput (Gp:) System integrators (Gp:) Deployment View (Gp:) System topology Delivery, installation Communication (Gp:) System engineering (Gp:) Use Case View
La promesa de MDA (Model Driven Architecture) De desarrollo basado en código a desarrollo basado en modelos
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)
| Página siguiente |