View
48
Download
0
Category
Tags:
Preview:
DESCRIPTION
Architect Academy Webcast #4: Diseñando la arquitectura. Billy 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 - PowerPoint PPT Presentation
Citation preview
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
Recommended