Architect AcademyWebcast #4:

Diseñando la arquitecturaBilly Reynoso Universidad de Buenos Aires

billyr@microsoft.com.ar

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

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

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

Estilos de Arquitectura

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

Estilos de Código Móvil• Arquitectura de Máquinas

VirtualesEstilos 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

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

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

ADL Fecha Investigador - Organismo ObservacionesAcme 1995 Monroe & Garlan (CMU), Wile (USC) Lenguaje de intercambio de ADLsAesop 1994 Garlan (CMU) ADL de propósito general, énfasis

en estilosArTek 1994 Terry, Hayes-Roth, Erman

(Teknowledge, DSSA)Lenguaje específico de dominio -No es ADL

Armani 1998 Monroe (CMU) ADL asociado a AcmeC2 SADL 1996 Taylor/Medvidovic (UCI) ADL específico de estiloCHAM 1990 Berry / Boudol Lenguaje de especificaciónDarwin 1991 Magee, Dulay, Eisenbach, Kramer ADL con énfasis en dinámicaJacal 1997 Kicillof , Yankelevich (Universidad de

Buenos Aires)Adl - Notación de alto nivel paradescripción y prototipado

LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexión de módulosMetaH 1993 Binns, Englehart (Honeywell) ADL específico de dominioRapide 1990 Luckham (Stanford) ADL & simulaciónSADL 1995 Moriconi, Riemenschneider (SRI) ADL con énfasis en mapeo de

refinamientoUML 1995 Rumbaugh, Jacobson, Booch (Rational) Lenguaje genérico de modelado –

No es ADLUniCon 1995 Shaw (CMU) ADL de propósito general, énfasis

en conectores y estilosWright 1994 Garlan (CMU) ADL de propósito general, énfasis

en comunicaciónxADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML

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)

ADLs

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

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

Acme/Armani

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

Aesop (inactivo?)

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

C2 SADL, C2SADEL SADL

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

C2

C2

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

CHAMEjemplo de compilador Lisp

Jacal (1/2)

http://www.microsoft.com/spanish/msdn/arquitectura

Jacal (2/2)

MetaH / AADL

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

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

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

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

UML y Arquitectura

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

UMLLimitaciones 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

UMLLimitaciones 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

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

UMLLimitaciones 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

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

UMLLimitaciones arquitectónicas

Este diagrama de clases muestra tres clases, una relación de herencia y una de agregación

En Java esto resultaría enpublic 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()?

UMLLimitaciones arquitectónicas En Rational Rose 2001.03.00 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

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

UMLLimitaciones 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

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.

OMG - MDA

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

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

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• http://www.sei.cmu.edu/publications/publications.html

Estudios de casos en Microsoft• http://www.microsoft.com/resources/casestudies ...

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…

Referencias y recursos

¿Preguntas?

billyr@microsoft.com.ar