Especificación y Modelado de Arquitecturas Software



Descargar 34,6 Kb.
Fecha de conversión19.03.2017
Tamaño34,6 Kb.

Especificación y Modelado de Arquitecturas Software

  • Raquel Anaya
  • ranaya@eafit.edu.co

Agenda Conferencia

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)
  • 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.
  • 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

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

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

  • Cualidades
  • de la Arquitectura
  • Procesos
  • Representación
  • de la arquitectura
  • Qué?
  • Por qué?
  • Para qué?
  • Quién?
  • Características
  • Del Sistema
  • Arquitectura
  • Requerimientos
  • S/W
  • Satisface
  • Restringe
  • Organización
  • Arquitecto
  • Habilidades
  • Stakeholders
  • Define roles
  • Produce
  • Analiza
  • Defines
  • Tecnología
  • 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

  • arquitecto
  • gerente del
  • proyecto
  • líder de
  • mercadeo
  • usuario
  • final
  • soporte
  • aplicativo
  • cliente
  • Bajo costo
  • Rendimiento
  • del equipo
  • Corto tiempo en mercado
  • Bajo costo; ventajas con
  • productos similares
  • Funcionalidad
  • Rendimiento
  • Seguridad
  • usabilidad
  • modificabilidad
  • 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
  • Supporting Workflows
  • Management
  • Environment
  • 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

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

  • 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
  • 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

  • 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

  • El modelo representa funcionalidad y comportamiento sin detalles de la tecnología,
  • Modelo
  • Independiente
  • De
  • Plataforma
  • Modelo detallado con Pre y Post en (OCL) y con semantica de comportamiento (Action Semantic)
  • CIM

El proceso MDA: 3. Probar PIM

  • Modelo
  • Independiente
  • De
  • Plataforma
  • Entorno de
  • Animación del
  • Modelo
  • CIM

El proceso MDA: 4. Definir reglas de transformación

  • Modelo
  • Independiente
  • De
  • Plataforma
  • Entorno de
  • Animación del
  • Modelo
  • CIM
  • Reglas de
  • Transformación
  • PIM - PSM

El proceso MDA: 5. Marcar el modelo

  • Modelo
  • Independiente
  • De
  • Plataforma
  • Entorno de
  • Animación del
  • Modelo
  • CIM
  • Reglas de
  • Transformación
  • PIM - PSM
  • + Marcas para
  • transformación

El proceso MDA: 6. Generar PSM (Platform-Specific Model)

  • Platform- Independent
  • Model
  • Mapear PIM a tecnología de middleware específica
  • CORBA Model
  • Entorno de
  • Animación del
  • Modelo
  • CIM
  • + Marcas para
  • transformación

El proceso MDA: 6. Mapear a múltiples tecnologías

  • Platform- Independent
  • Model
  • CORBA Model
  • MDA tool applies an standard mapping to generate Platform-Specific Model (PSM) from the PIM. Code is partially automatic, partially hand-written.
  • Java/EJB Model
  • XML/SOAP Model
  • Other Model

El proceso MDA: 7. Generación de código

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

El proceso MDA: 8. Integrar aplicaciones legado y COTS

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

El proceso MDA: 9. Generación de adaptadores (bridges)

  • CORBA Model
  • XML/SOAP Model
  • Platform- Independent
  • Model
  • CORBA System
  • XML/SOAP
  • System
  • Interop
  • Bridge
  • MDA Tools combine application and platform knowledge to generate bridges

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?



La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal