Descargar la presentación
La descarga está en progreso. Por favor, espere
1
Architect Academy Webcast #4: Diseñando la arquitectura
Billy Reynoso Universidad de Buenos Aires
2
Webcast #1: ¿Qué es la Arquitectura de Software?
Roadmap Webcast #1: ¿Qué es la Arquitectura de Software? Webcast #2: Drilldown en Estilos de Arquitectura de Software Webcast #3: Arquitectura para distribución y agregación: Services Oriented Architecture (SOA) Webcast #4: Diseñando la arquitectura
3
Objetivos Propósito de la serie de Webcasts:
Comprender la teoría y orientar la práctica de la Arquitectura de Software Vincular concepciones de la academia y la industria Relacionar los principios teóricos con herramientas y ambientes Microsoft Propósito de la sesión de hoy: Conocer conceptos y herramientas de diseño arquitectónico de alto nivel, pero con impacto sobre código Disipar algunos malentendidos comunes Proporcionar referencias para profundizar en la práctica específica del diseño arquitectónico
4
Diseñando la Arquitectura
Temario Problemas y perspectivas del diseño arquitectónico Concepciones de diseño de la industria y la academia Vista rápida de los Lenguajes de Descripción de Arquitectura (ADL) ACME/Armani, Wright, CHAM, ADLs basados en C2 – xADL, Jacal La Arquitectura no es modelado en UML Los límites de UML (2) como lenguaje de modelado arquitectónico Perspectiva académica – No es el punto de vista de Microsoft Arquitectura de software y MDA Estado de arte del diseño arquitectónico: Sacando provecho de herramientas, patrones y prácticas – Factorías y DSLs Estudios de casos Visión del futuro – Integrando arquitectura, diseño y desarrollo en Visual Studio 2005 (Team System)
5
Estilos de Arquitectura
Estilos de Código Móvil Arquitectura de Máquinas Virtuales Estilos heterogéneos Sistemas de control de procesos Arquitecturas Basadas en Atributos Estilos Peer-to-Peer Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios Arquitecturas Basadas en Recursos Estilos de Flujo de Datos Tubería y filtros Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio Estilos de Llamada y Retorno Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes
6
ADLs Herramientas de modelado que soportan desarrollos basados en arquitecturas Estructura de alto nivel, no detalle de implementación Poco consenso respecto a definición de ADL, aspectos a considerar y adecuación de ADLs a estilos Poca distinción entre ADL, especificación formal, interconexión de módulos (MIL), herramientas de modelado y hasta lenguajes de programación
7
Condiciones de la descripción arquitectónica
Componentes, con aserción de propiedades, interfaces e implementaciones Conectores, con aserción de protocolos, interfaces e implementaciones Configuraciones o sistemas, abstracción y encapsulamiento Propiedades no funcionales Restricciones Estilos Evolución Herramientas de verificación
9
Otras herramientas Lenguajes de especificacíón (LARCH, Z)
Lenguajes de prototipado (Modechart, PSDL) Lenguajes de modelado (UML) Lenguajes de programación (CODE, Ada) Herramientas para definición de ciclo de vida (UNAS/SALE) Lenguajes específicos de dominio (DSLs)
10
ADLs
11
Acme / Armani Lenguaje de intercambio de arquitectura
1995, Carnegie Mellon Lenguaje Acme Acme Tool Developer’s Library (AcmeLib) 4 tipos de arquitectura Estructura, propiedades (comportamiento), restricciones, tipos y estilos Estructura: componentes, conectores, sistemas, puertos, roles, representaciones y rep-mapas
12
Acme/Armani Semántica sólo como comentario No genera código
Maneja estilos (familia) Varias herramientas en ambiente Windows: AcmeStudio Armani con front-end Visio ISI: front-end Powerpoint ADML: lenguaje de markup de arquitectura, derivado de Acme (estándar) Armani: ADL. Declarativo
13
Acme/Armani
18
ADML Open Group, 2000 ADML: XML con DTD
xADL (“Zaydal”,UCI): Schemas para estilos (Aplicación de xArch) xArch (UCI/Carnegie Mellon): lenguaje basado en XML para descripción de arquitecturas – Placeholder para implementaciones variables
19
Aesop (inactivo?)
20
C2 SADL, C2SADEL C2 SADL (Simulation Architecture Description Language) ADL que permite describir arquitecturas en estilo C2 C2SADEL – Variante. Incluye DRADEL (Development of Robust Architectures using a Description and Evolution Language) xArch, xADL: Inicialmente ligados a C2
21
C2 SADL, C2SADEL SADL Windows: Módulos declarativos e imperativos
1) IDN Interface Description Notation 2) ADN Architecture Description Notation 3) ACN Architecture Construction Notation Windows: DRADEL (Int. Para C2SADEL) SAAGE (requiere Rose o Dradel) ArchStudio – Argo (discontinuado)
22
C2
23
C2
24
CHAM Chemical Abstract Machine
Técnica de especificación basada en álgebra de procesos Moléculas (componentes básicos) Soluciones de moléculas (multiconjuntos que definen estados) Reglas de transformación (cambios de estado) – No determinismo si hay + de una regla para una molécula o solución
25
CHAM Ejemplo de compilador Lisp
28
Jacal (1/2)
29
Jacal (2/2)
35
MetaH / AADL
36
Wright (1/2) Herramienta de formalización de conexiones arquitectónicas, CMU (parte de proyecto ABLE) ABLE: herramienta de diseño (Aesop), especificación formal (Wright) Integración de metodología formal con descripciones arquitectónicas Aplica procesos formales (álgebra de proceso y refinamiento de proceso) a verificación automatizada de propiedades de arquitectura
37
Wright (2/2) Declara conjunto de tipos de componentes y conectores y conjunto de restricciones Modelo semántico basado en CSP (Communicating Sequential Process de Hoare) Verificación mediante verificador comercial FDR Restricciones: predicado que debe ser satisfecho por cualquier configuración que se declare miembro del estilo Notación de restricciones: cálculo de predicados de primer orden Sub-estilos: heredan de estilos No posee interfaz gráfica nativa No genera código ejecutable
39
Modelos formales Darwin: cálculo Pi
Wright: CSP, lógica de primer orden LILEANNA: programación parametrizada e hiper-programación Rapide: Posets SAM: Redes de Petri de transición de predicados, lógica temporal de primer orden Jacal: Redes de Petri Casi todos los ADLs tienen BNF Modelo estructural no ligado a OO
40
Conclusiones respecto de ADLs
No hay ninguno que sea dominante en la academia o la industria Deben reformularse para vincularse con XML y UML 2 Muchos de ellos sin actividad en los últimos años Algunos son específicos de industrias pesadas Poco énfasis en desarrollo de ADLs en SEI/CMU Momento de transición Extensiones arquitectónicas de UML 2, MDA, DSLs Adopción de modelos abstractos y factorías en la industria Modelado comienza a vincularse a herramientas de desarrollo No se quiere repetir la experiencia de los CASE
41
UML y Arquitectura
42
UML Limitaciones arquitectónicas
Hofmeister, 1999: La notación gráfica de UML es deficiente para mostrar correspondencias entre elementos en diferentes vistas. Esto se logra mejor con una tabla. Protocolos: no se puede mostrar comunicación peer-to-peer en UML [1]. Hay que utilizar una notación externa, como ROOM (Real-time Object-Oriented Modeling). Puertos en componentes. La notación es confusa y requiere (p. ej.) anidamiento. Una notación “lollipop” sería preferible. Aspectos dinámicos de la estructura. Diagramas de secuencia y de estado describen la conducta dinámica, pero no soportan configuración dinámica (ni siquiera para estilos basados en objeto).
43
UML Limitaciones arquitectónicas
Abdurazik, 2000 Los diagramas de componentes de UML no representan la descomposición lógica de un sistema en subsistemas reutilizables y combinables UML no proporciona concepto de conectores como objetos de primera clase Estos serían un híbrido de una clase de asociación y una dependencia entre una clase y una interface de otra clase. UML se puede extender para modelar cualquier cosa, pero se pierde soporte de herramientas e intercambiabilidad
44
UML Limitaciones arquitectónicas
Cuestionamientos genéricos (reconocidos por OMG) Tamaño excesivo (al mismo tiempo demasiado y demasiado poco) Semántica ambigua “Puede parecer visualmente clara, pero las intuiciones subyacentes son confusas” (Garlan) La interpretación de los tipos de UML difiere entre stakeholders con distinta formación e intereses (Perrouin 2002) La semántica no está formalmente definida, sino librada a la imaginación del usuario (Klaus-Dieter Schewe) Relaciones ambiguas y oscuras entre vistas, no susceptibles de tratamiento formal Extensibilidad a costa del soporte de herramientas y de una especificación estándar Adaptabilidad (customización) limitada
45
UML Limitaciones arquitectónicas
Cuestionamientos genéricos (cont.) Soporte insatisfactorio para desarrollo basado en componentes Posibilidad de incurrir en el “síndrome de la segunda versión” (Brooks) Poca orientación semántica para arquitectos (p.ej. cuándo usar un diagrama) “In-analisibilidad” (Garlan) “Aunque se lo pueda representar, y luzca bien, no hay nada que se pueda hacer con él, excepto usarlo como documentación” Falta de soporte para estilos Como profiles el manejo es pesado; como packages se soporta agregación, pero no restricciones (Garlan)
46
UML Limitaciones arquitectónicas
Guéhéneuc-Amiot-Douence-Cointe (2002) UML y lenguajes OO tienen conceptos de clase y herencia. Pero hay nociones que existen en UML y no en lenguajes: estereotipo, relaciones de clases binarias (asociación, agregación, composición)* La definición de relaciones binarias en UML está en lenguaje natural y es ambigua; no hay lineamientos sobre su implementación. * Ver diagramas en Enterprise Architect, eventualmente
47
UML Limitaciones arquitectónicas
Guéhéneuc-Amiot-Douence-Cointe (2002, cont.) Las herramientas (Rational Rose, Together, Borland Jbuilder, ArgoUML) no tienen definiciones claras de relaciones binarias. Las distinguen gráficamente, pero el código generado es el mismo. Clases Asociadas: ocurren juntas (Factura – Vendedor); 2 elementos tienen una relación- Línea continua Composición: una clase es parte de otra (Item-Factura) – Línea con rombo lleno en clase mayor – Forma fuerte de agregación Agregación: Sin herencia (p.ej. Orden de compra tiene un cliente) – Rombo sin relleno. Una clase es usada por otra.
48
UML Limitaciones arquitectónicas
Este diagrama de clases muestra tres clases, una relación de herencia y una de agregación En Java esto resultaría en public class A { ... } public class B extends A { public class C { ¿Cómo se implementa la relación de agregación entre B y C? ¿Como campo? ¿Como colección? ¿Como par de getter y setter? ¿Como par de métodos add()-remove()?
49
UML Limitaciones arquitectónicas
En Rational Rose este diagrama de dos clases con una relación de agregación genera el mismo código Java que para relaciones de asociación y composición, aunque sus semánticas y notaciones sean distintas Cuando se reemplaza el array por una colección instancia de java.util.vector p.ej. (como se hace habitualmente) y se hace ingeniería reversa del código para generar UML, desaparece la agregación, y aparece una asociación inconsistente con el diagrama original
50
UML Limitaciones arquitectónicas
Martin Glinz - Deficiencias de UML como lenguaje de especificación de requisitos UML no puede modelar interacciones iniciadas por el sistema (y no por un actor) UML prohibe explícitamente establecer relaciones entre actores, perdiendo capacidad para expresar contextos complejos UML no permite expresar estructuras ni jerarquías entre casos de uso UML no permite relaciones entre casos de uso (p. ej. un caso que requiera la finalización de otro)
51
UML Limitaciones arquitectónicas
Martin Glinz - Deficiencias de UML como lenguaje de especificación de requisitos (Cont.) No se pueden modelar máquinas de estado gobernadas por un conjunto de casos de uso El modelado de flujos de información en un sistema consistente en subsistemas no está bien resuelto en UML UML no puede modelar el comportamiento de subsistemas de alto nivel UML no puede modelar la descomposición de un sistema distribuido UML no puede modelar todos los aspectos de un sistema complejo en una sola vista
52
UML y arquitectura Se recomienda el uso de UML para:
Esbozos genéricos o puntuales. White boarding. “Servilletas”. Documentación. Dibujos conceptuales que no se relacionan con código en forma directa. Se recomendarían DSLs para: Abstracciones precisas a partir de las cuales se generará código. Abstracciones precisas que mapean sobre puntos de variaci´´on en frameworks y componentes. Mapeados precisos entre DSLs. Dibujos conceptuales que tienen mapeados precisos y especificables sobre otros DSLs o sobre artefactos de código.
57
OMG - MDA
58
No cubierto por MDA Capturar, analizar y administrar requerimientos, identificando relaciones entre ellos, el diseño arquitectónico y la implementación y permitiendo validar si los requerimientos han sido satisfechos Definir AS de manera que soporte análisis de seguridad, performance y confiabilidad y que permita transformaciones en dos vías desde el requerimiento hasta el despliegue Definir empaquetado de componentes ejecutables del sistema Definir casos de prueba, lotes de prueba y otros artefactos, permitiendo administrar y mostrar los resultados Identificar relaciones trazables entre los modelos y otros artefactos, permitiendo evaluar impacto de negocios por caída del sistema, configurar sistemas para satisfacer requerimientos y forzar constraints durante la configuración Permitir manejo de versión y asociar reportes y solicitudes de cambio con versiones específicas
59
DSLs “Think of a DSL as a small, highly focused language for solving some clearly identifiable problem that an analyst, architect, developer, tester, or system administrator must wrestle with. Developers are already familiar with examples of DSLs; SQL for data manipulation, XSD for XML document structure definition, and so on. Another example from Visual Studio Team Edition for Software Architects is a DSL for modeling the logical structure of datacenter hardware and host software configurations. This DSL and its related graphical designer can be used to validate during design time that applications are configured to match their intended deployment targets, alerting the developer to problems when they can be fixed more cheaply”.
60
Referencias de Casos Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice, 2ª edición Estudios de casos en documentación del SEI en Carnegie Mellon Estudios de casos en Microsoft ...
62
Conclusiones generales
Importancia de la Arquitectura de Software Alto nivel de abstracción Vinculada con requerimientos no funcionales Criticidad de las decisiones tempranas de arquitectura Fuerte impulso en la academia y la industria Herramientas arquitectónicas aún en proceso de definición y desarrollo Metodologías arquitectónicas, en proceso de elaboración preliminar Resta elaborar: tácticas arquitectónicas, métodos basados en arquitectura, vínculo entre conceptos de arquitectura, DSLs, factorías, building blocks, MSF…
63
Referencias y recursos
71
¿Preguntas?
Presentaciones similares
