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 anterior | Volver al principio del trabajo | Página siguiente  |